draft-ietf-ecrit-lost-10.txt   rfc5222.txt 
ECRIT T. Hardie Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc. Request for Comments: 5222 Qualcomm, Inc.
Intended status: Standards Track A. Newton Category: Standards Track A. Newton
Expires: November 28, 2008 American Registry for Internet American Registry for Internet Numbers
Numbers
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
May 27, 2008 August 2008
LoST: A Location-to-Service Translation Protocol LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-10.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 28, 2008. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document describes an XML-based protocol for mapping service This document describes an XML-based protocol for mapping service
identifiers and geodetic or civic location information to service identifiers and geodetic or civic location information to service
contact URIs. In particular, it can be used to determine the contact URIs. In particular, it can be used to determine the
location-appropriate Public Safety Answering Point (PSAP) for location-appropriate Public Safety Answering Point (PSAP) for
emergency services. emergency services.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction .................................................. 3
2. Terminology and Requirements Notation . . . . . . . . . . . . 6 2. Terminology and Requirements Notation ......................... 4
3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7 3. Overview of Protocol Usage .................................... 5
4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 9 4. LoST Servers and Their Resolution ............................ 6
5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10 5. The <mapping> Element ........................................ 7
5.1. The Mapping Data Source: 'source', 'sourceId' and 5.1. The Mapping Data Source: 'source', 'sourceId', and
'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10 'lastUpdated' Attributes .................................. 7
5.2. Mapping Validity: The 'expires' Attribute . . . . . . . . 10 5.2. Mapping Validity: The 'expires' Attribute ................ 8
5.3. Describing the Service with the <displayName> Element . . 11 5.3. Describing the Service with the <displayName> Element .... 8
5.4. The Mapped Service: the <service> Element . . . . . . . . 11 5.4. The Mapped Service: The <service> Element ................. 8
5.5. Defining the Service Region with the <serviceBoundary> 5.5. Defining the Service Region with the <serviceBoundary>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 11 Element .................................................. 9
5.6. Service Boundaries by Reference: the 5.6. Service Boundaries by Reference: The
<serviceBoundaryReference> Element . . . . . . . . . . . . 12 <serviceBoundaryReference> Element ........................ 9
5.7. The Service Number: the <serviceNumber> Element . . . . . 13 5.7. The Service Number: The <serviceNumber> Element ......... 10
5.8. Service URLs: the <uri> Element . . . . . . . . . . . . . 13 5.8. Service URLs: The <uri> Element ......................... 10
6. Path of a Request: the <path> Element . . . . . . . . . . . . 14
6. Path of a Request: The <path> Element ....................... 10
7. Identifying the Location Element Used for Mapping: 7. Identifying the Location Element Used for Mapping:
<locationUsed> . . . . . . . . . . . . . . . . . . . . . . . . 15 <locationUsed> ............................................... 11
8. Mapping a Location and Service to URLs: <findService> . . . . 16 8. Mapping a Location and Service to URLs: <findService> ....... 11
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Overview ................................................. 11
8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Examples ................................................. 11
8.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 16 8.2.1. Example Using Geodetic Coordinates ................... 11
8.2.2. Civic Address Mapping Example . . . . . . . . . . . . 17 8.2.2. Civic Address Mapping Example ....................... 13
8.3. Components of the <findService> Request . . . . . . . . . 19 8.3. Components of the <findService> Request ................. 15
8.3.1. The <location> Element . . . . . . . . . . . . . . . . 19 8.3.1. The <location> Element ............................... 15
8.3.2. Identifying the Service: The <service> Element . . . 20 8.3.2. Identifying the Service: The <service> Element ..... 16
8.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 20 8.3.3. Recursion and Iteration ............................. 16
8.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 20 8.3.4. Service Boundary ..................................... 16
8.3.5. Requesting Civic Location Validation . . . . . . . . . 20 8.3.5. Requesting Civic Location Validation ................. 16
8.4. Components of the Mapping Response 8.4. Components of the Mapping Response
<findServiceResponse> . . . . . . . . . . . . . . . . . . 22 <findServiceResponse> ................................... 18
8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 8.4.1. Overview ............................................. 18
8.4.2. Civic Address Validation: the 8.4.2. Civic Address Validation: The <locationValidation>
<locationValidation> Element . . . . . . . . . . . . . 23 Element ............................................. 19
9. Retrieving the Service Boundary via <getServiceBoundary> . . . 24 9. Retrieving the Service Boundary via <getServiceBoundary> ..... 19
10. List Services: <listServices> . . . . . . . . . . . . . . . . 27 10. List Services: <listServices> ............................... 21
11. List Services By Location: <listServicesByLocation> . . . . . 28 11. List Services By Location: <listServicesByLocation> ......... 22
12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30 12. Location Profiles ........................................... 24
12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31 12.1. Location Profile Usage ................................... 25
12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34 12.2. Two-Dimensional Geodetic Profile ......................... 30
12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 36 12.3. Basic Civic Profile ..................................... 31
13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37 13. Errors, Warnings, and Redirects ............................. 32
13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1. Errors ................................................... 32
13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.2. Warnings ................................................. 34
13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40 13.3. Redirects ............................................... 36
14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42 14. LoST Transport: HTTP ......................................... 36
15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43 15. Relax NG Schema ............................................. 37
16. Internationalization Considerations . . . . . . . . . . . . . 50 16. Internationalization Considerations ......................... 44
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 17. IANA Considerations ......................................... 44
17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51 17.1. U-NAPTR Registrations ................................... 44
17.2. Content-type registration for 'application/lost+xml' . . . 51 17.2. Content-Type Registration for 'application/lost+xml' ..... 44
17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 17.3. LoST Relax NG Schema Registration ....................... 46
17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 17.4. LoST Namespace Registration ............................. 46
17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 17.5. LoST Location Profile Registry ........................... 47
18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 18. Security Considerations ..................................... 47
19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 19. Acknowledgments ............................................. 48
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 20. References ................................................... 51
20.1. Normative References . . . . . . . . . . . . . . . . . . . 60 20.1. Normative References ..................................... 51
20.2. Informative References . . . . . . . . . . . . . . . . . . 61 20.2. Informative References ................................... 52
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 62 Appendix A. Non-Normative RELAX NG Schema in XML Syntax ......... 54
Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 76 Appendix B. Examples Online ..................................... 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77
Intellectual Property and Copyright Statements . . . . . . . . . . 78
1. Introduction 1. Introduction
Protocols such as NAPTR records and the Service Location Protocol Protocols such as Naming Authority Pointer (NAPTR) records and the
(SLP) can be used to discover servers offering a particular service. Service Location Protocol (SLP) can be used to discover servers
However, for an important class of services the appropriate specific offering a particular service. However, for an important class of
service instance depends both on the identity of the service and the services the appropriate specific service instance depends both on
geographic location of the entity that needs to reach it. Emergency the identity of the service and the geographic location of the entity
telecommunications services are an important example; here, the that needs to reach it. Emergency telecommunications services are an
service instance is a Public Safety Answering Point (PSAP) that has important example; here, the service instance is a Public Safety
jurisdiction over the location of the user making the call. The Answering Point (PSAP) that has jurisdiction over the location of the
desired PSAP isn't necessarily the one that is topologically or even user making the call. The desired PSAP isn't necessarily the one
line-of-sight closest to the caller; rather, it is the one that that is topologically or even line-of-sight closest to the caller;
serves the caller's location based on jurisdictional boundaries. rather, it is the one that serves the caller's location based on
jurisdictional boundaries.
This document describes a protocol for mapping a service identifier This document describes a protocol for mapping a service identifier
and location information compatible with PIDF-LO [6] to one or more and location information compatible with the Presence Information
service URIs. Service identifiers take the form of the service URNs 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 described in [9]. Location information here includes revised civic
location information [10] and a subset of the PIDL-LO profile [13] location information [10] and a subset of the PIDF-LO profile [13],
which consequently includes the Geo-Shapes [12] defined for GML [11]. which consequently includes the Geo-Shapes [12] defined for GML [11].
Example service URI schemes include sip [14], xmpp [15], and tel Example service URI schemes include sip [14], xmpp [15], and tel
[16]. While the initial focus is on providing mapping functions for [16]. While the initial focus is on providing mapping functions for
emergency services, it is likely that the protocol is applicable to emergency services, it is likely that the protocol is applicable to
other service URNs. For example, in the United States, the "2-1-1" other service URNs. For example, in the United States, the "2-1-1"
and "3-1-1" service numbers follow a similar location-to-service and "3-1-1" service numbers follow a similar location-to-service
behavior as emergency services. behavior as emergency services.
This document names this protocol "LoST", for Location-to-Service This document names this protocol "LoST", for Location-to-Service
Translation. LoST Satisfies the requirements [18] for mapping Translation. LoST satisfies the requirements [18] for mapping
protocols. LoST provides a number of operations, centered around protocols. LoST provides a number of operations, centered around
mapping locations and service URNs to service URLs and associated mapping locations and service URNs to service URLs and associated
information. LoST mapping queries can contain either civic or information. LoST mapping queries can contain either civic or
geodetic location information. For civic addresses, LoST can geodetic location information. For civic addresses, LoST can
indicate which parts of the civic address are known to be valid or indicate which parts of the civic address are known to be valid or
invalid, thus providing address validation, as described in Section invalid, thus providing address validation, as described in Section
3.5 of [18]. LoST indicates errors in the location data to 3.5 of [18]. LoST indicates errors in the location data to
facilitate debugging and proper user feedback, but also provides facilitate debugging and proper user feedback, but also provides
best-effort answers. best-effort answers.
skipping to change at page 5, line 15 skipping to change at page 4, line 19
This document focuses on the description of the protocol between the This document focuses on the description of the protocol between the
mapping client and the mapping server. Other functions, such as mapping client and the mapping server. Other functions, such as
discovery of mapping servers, data replication and the overall discovery of mapping servers, data replication and the overall
mapping server architecture are described in a separate document mapping server architecture are described in a separate document
[19]. [19].
The query message carries location information and a service The query message carries location information and a service
identifier encoded as a Uniform Resource Name (URN) (see [9]) from identifier encoded as a Uniform Resource Name (URN) (see [9]) from
the LoST client to the LoST server. The LoST server uses its the LoST client to the LoST server. The LoST server uses its
database to map the input values to one or more Uniform Resource database to map the input values to one or more Uniform Resource
Identifiers (URI) and returns those URIs along with optional Identifiers (URIs) and returns those URIs along with optional
information, such as hints about the service boundary, in a response information, such as hints about the service boundary, in a response
message to the LoST client. If the server cannot resolve the query message to the LoST client. If the server cannot resolve the query
itself, it may in turn query another server or return the address of itself, it may in turn query another server or return the address of
another LoST server, identified by a LoST server name. In addition another LoST server, identified by a LoST server name. In addition
to the mapping function described in Section 8, the protocol also to the mapping function described in Section 8, the protocol also
allows to retrieve the service boundary (see Section 9) and to list allows to retrieve the service boundary (see Section 9) and to list
the services available for a particular location (see Section 11) or the services available for a particular location (see Section 11) or
supported by a particular server (see Section 10). supported by a particular server (see Section 10).
2. Terminology and Requirements Notation 2. Terminology and Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
This document uses the following terms: This document uses the following terms:
Mapping: Mapping is a process that takes a location and a service Mapping:
Mapping is a process that takes a location and a service
identifier as inputs and returns one or more URIs. Those URIs can identifier as inputs and returns one or more URIs. Those URIs can
either point to a host providing that service or to a host that in point either to a host providing that service or to a host that in
turn routes the request to the final destination. This definition turn routes the request to the final destination. This definition
is a generalization of the term "mapping" as used in [18], because is a generalization of the term "mapping" as used in [18], because
LoST can be used for non-emergency services. LoST can be used for non-emergency services.
LoST client: A host acts as a LoST client if it sends LoST query LoST client:
messages and receives LoST response messages. 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 LoST server:
messages and sends LoST response messages. In recursive A host acts as a LoST server if it receives LoST query messages
operation, the same entity may be both a client and a server. 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 Authoritative LoST server:
server and successfully resolves the input location and service An authoritative server acts only as a server and successfully
identifier to a URI or set of URIs. resolves the input location and service identifier to a URI or set
of URIs.
Service boundary: A service boundary circumscribes the region within Service boundary:
which all locations map to the same service URI or set of URIs for A service boundary circumscribes the region within which all
a given service. A service boundary may consist of several non- locations map to the same service URI or set of URIs for a given
contiguous geometric shapes. service. A service boundary may consist of several non-contiguous
geometric shapes.
Validation: Validation:
The term "validation" describes the behavior defined as "location The term "validation" describes the behavior defined as "location
validation" in Section 3.5 of [18]. validation" in Section 3.5 of [18].
Additional emergency service terminology can be found in [18]. Additional emergency service terminology can be found in [18].
3. Overview of Protocol Usage 3. Overview of Protocol Usage
The LoST protocol supports the following type of queries and The LoST protocol supports the following types of queries and
responses: responses:
<findService> and <findServiceResponse> <findService> and <findServiceResponse>
A LoST client retrieves contact URIs based on location information A LoST client retrieves contact URIs based on location information
and a service identifier with this request and response. The same and a service identifier with this request and response. The same
query type may also ask for location validation and for service query type may also ask for location validation and for service
numbers, either combined with a mapping request or separately. numbers, either combined with a mapping request or separately.
The details can be found in Section 8 and Section 8.4. The details can be found in Section 8.
<getServiceBoundary> and <getServiceBoundaryResponse> <getServiceBoundary> and <getServiceBoundaryResponse>
A LoST client obtains a service boundary with this request and A LoST client obtains a service boundary with this request and
response, as described in Section 9. response, as described in Section 9.
<listServices> and <listServicesResponse> <listServices> and <listServicesResponse>
With this request and response, a LoST client can find out which With this request and response, a LoST client can find out which
services a LoST server supports, as described in Section 10. services a LoST server supports, as described in Section 10.
<listServicesByLocation> and <listServicesByLocationResponse> <listServicesByLocation> and <listServicesByLocationResponse>
A LoST client can determine with this request and response which A LoST client can determine with this request and response which
services are available for a specific location region. Section 11 services are available for a specific location region. Section 11
describes the details. describes the details.
LoST clients may initiate any of the above queries at any time. LoST clients may initiate any of the above queries at any time.
Among the common triggers are: Among the common triggers are:
1. When the client initially starts up or attaches to a network; 1. when the client initially starts up or attaches to a network;
2. when the client detects that its location has changed 2. when the client detects that its location has changed
sufficiently that it is outside the bounds of the service region; sufficiently that it is outside the bounds of the service region;
3. when a SIP message arrives at a SIP proxy performing location- 3. when a SIP message arrives at a SIP proxy performing location-
based call routing; based call routing;
4. when cached mapping information has expired; 4. when cached mapping information has expired; and
5. when invoking a particular service. At that time, a client may 5. when invoking a particular service. At that time, a client may
omit requests for service boundaries or other auxiliary omit requests for service boundaries or other auxiliary
information. information.
A service-specific Best Current Practice (BCP) document, such as A service-specific Best Current Practice (BCP) document, such as
[21], governs whether a client is expected to invoke the mapping [21], governs whether a client is expected to invoke the mapping
service just before needing the service or whether to rely on cached service just before needing the service or whether to rely on cached
answers. Cache entries expire at their expiration time (see answers. Cache entries expire at their expiration time (see
Section 5.2), or they become invalid if the caller's device moves Section 5.2), or they become invalid if the caller's device moves
beyond the boundaries of the service region. Service-specific Best beyond the boundaries of the service region. Service-specific Best
Curent Practice documents may also provide guidance on the contact Current Practice documents may also provide guidance on the contact
URI schemes most appropriate to the service. As a general set of URI schemes most appropriate to the service. As a general set of
guidelines, URI schemes that do not provide mechanisms for actually guidelines, URI schemes that do not provide mechanisms for actually
initiating a contact method should be avoided (examples include data, initiating a contact method should be avoided (examples include data,
info, cid, and tag) as transforming those references into contact info, cid, and tag) as transforming those references into contact
mechanisms requires a layer of indirection that makes the overall mechanisms requires a layer of indirection that makes the overall
mechanism more fragile. Provisionally registered URI schemes should mechanism more fragile. Provisionally registered URI schemes should
also be carefully considered before use, because they are subject to also be carefully considered before use, because they are subject to
change in core semantics. change in core semantics.
4. LoST Servers and Their Resolution 4. LoST Servers and Their Resolution
LoST servers are identified by U-NAPTR/DDDS [8] application unique LoST servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/
strings, in the form of a DNS name. An example is Dynamic Delegation Discovery Service) [8] application unique strings,
'lostserver.example.com'. 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 Clients need to use the U-NAPTR [8] specification described below to
obtain a URI (indicating host and protocol) for the applicable LoST obtain a URI (indicating host and protocol) for the applicable LoST
service. In this document, only the HTTP and HTTPS URL schemes are 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 defined. Note that the HTTP URL can be any valid HTTP URL, including
those containing path elements. those containing path elements.
The following two DNS entries show the U-NAPTR resolution for The following two DNS entries show the U-NAPTR resolution for
"example.com" to the HTTPS URL https://lostserv.example.com/secure or "example.com" to the HTTPS URL https://lostserv.example.com/secure or
the HTTP URL http://lostserver.example.com, with the former being the HTTP URL http://lostserver.example.com, with the former being
skipping to change at page 9, line 31 skipping to change at page 7, line 14
example.com. example.com.
IN NAPTR 100 10 "u" "LoST:https" IN NAPTR 100 10 "u" "LoST:https"
"!.*!https://lostserver.example.com/secure!" "" "!.*!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http" IN NAPTR 200 10 "u" "LoST:http"
"!.*!http://lostserver.example.com!" "" "!.*!http://lostserver.example.com!" ""
Clients learn the LoST server's host name by means beyond the scope Clients learn the LoST server's host name by means beyond the scope
of this specification, such as SIP configuration and DHCP. of this specification, such as SIP configuration and DHCP [25].
5. The <mapping> Element 5. The <mapping> Element
The <mapping> element is the core data element in LoST, describing a The <mapping> element is the core data element in LoST, describing a
service region and the associated service URLs. Its attributes and service region and the associated service URLs. Its attributes and
elements are described in subsections below. elements are described in subsections below.
5.1. The Mapping Data Source: 'source', 'sourceId' and 'lastUpdated' 5.1. The Mapping Data Source: 'source', 'sourceId', and 'lastUpdated'
Attributes Attributes
The 'source', the 'sourceId' and the 'lastUpdated' attributes The 'source', 'sourceId', and 'lastUpdated' attributes uniquely
uniquely identify a particular mapping record. They are created by identify a particular mapping record. They are created by the
the authoritative source for a mapping and are never modified when a authoritative source for a mapping and are never modified when a
mapping is served from a cache. All three attributes are REQUIRED mapping is served from a cache. All three attributes are REQUIRED
for all <mapping> elements. A receiver can replace a mapping with for all <mapping> elements. A receiver can replace a mapping with
another one having the same 'source' and 'sourceId' and a more recent another one having the same 'source' and 'sourceId' and a more recent
time in 'lastUpdated'. time in 'lastUpdated'.
The 'source' attribute contains a LoST application unique string The 'source' attribute contains a LoST application unique string
identifying the authoritative generator of the mapping (Section 4). identifying the authoritative generator of the mapping (Section 4).
The 'sourceId' attribute identifies a particular mapping and contains The 'sourceId' attribute identifies a particular mapping and contains
an opaque token that MUST be unique among all different mappings an opaque token that MUST be unique among all different mappings
maintained by the authoritative source for that particular service. maintained by the authoritative source for that particular service.
For example, a Universally Unique Identifier (UUID) is a suitable For example, a Universally Unique Identifier (UUID) is a suitable
format. format.
The 'lastUpdated' attribute describes when a specific instance of The 'lastUpdated' attribute describes when a specific instance of
mapping, identified by the combination of 'source' and 'sourceId', mapping, identified by the combination of 'source' and 'sourceId',
was last changed. The contents of this attribute has the XML data was last changed. The contents of this attribute has the XML data
type dateTime in its timezoned form, using canonical UTC type dateTime in its timezoned form, using the canonical UTC
representation with the letter 'Z' as the timezone indicator. representation with the letter 'Z' as the timezone indicator.
5.2. Mapping Validity: The 'expires' Attribute 5.2. Mapping Validity: The 'expires' Attribute
The 'expires' attribute contains the absolute time at which the The 'expires' attribute contains the absolute time at which the
mapping becomes invalid. The contents of this attribute is a mapping becomes invalid. The contents of this attribute is a
timezoned XML type dateTime, in canonical representation. See timezoned XML type dateTime, in canonical representation. The
Section 3 regarding how this value is to be utilized with a cache. <mapping> element MUST include the 'expires' attribute.
The 'expires' attribute is REQUIRED to be included in the <mapping>
element.
Optionally, this attribute may contain the values of 'NO-CACHE' and Optionally, this attribute may contain the values of 'NO-CACHE' and
'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is
an indication that the mapping should not be cached. The value of an indication that the mapping should not be cached. The value of
'NO-EXPIRATION' is an indication that the mapping does not expire. 'NO-EXPIRATION' is an indication that the mapping does not expire.
On occasion, a server may be forced to return an expired mapping if On occasion, a server may be forced to return an expired mapping if
it cannot reach the authoritative server or the server fails to it cannot reach the authoritative server or the server fails to
return a usable answer. Clients and servers MAY cache the mapping so return a usable answer. Clients and servers MAY cache the mapping so
that they have at least some information available. Caching servers that they have at least some information available. Caching servers
skipping to change at page 11, line 20 skipping to change at page 8, line 35
expired, local policy at the client determines whether it discards expired, local policy at the client determines whether it discards
the answer and tries again later or uses the possibly stale response. the answer and tries again later or uses the possibly stale response.
5.3. Describing the Service with the <displayName> Element 5.3. Describing the Service with the <displayName> Element
Zero or more <displayName> elements describe the service with a Zero or more <displayName> elements describe the service with a
string that is suitable for display to human users, each annotated string that is suitable for display to human users, each annotated
with the 'xml:lang' attribute that contains a language tag to aid in with the 'xml:lang' attribute that contains a language tag to aid in
the rendering of text. the rendering of text.
5.4. The Mapped Service: the <service> Element 5.4. The Mapped Service: The <service> Element
The mandatory <service> element identifies the service for which this The mandatory <service> element identifies the service for which this
mapping applies. Two cases need to be distinguished when the LoST mapping applies. Two cases need to be distinguished when the LoST
server sets the <service> element in the response message: server sets the <service> element in the response message:
1. If the requested service, identified by the service URN [9] in 1. If the requested service, identified by the service URN [9] in
the <service> element of the request, exists for the location the <service> element of the request, exists for the location
indicated, then the LoST server copies the service URN from the indicated, then the LoST server copies the service URN from the
request into the <service> element. request into the <service> element.
2. If, however, the requested service, identified by the service URN 2. If, however, the requested service, identified by the service URN
[9] in the <service> element in the request, does not exist for [9] in the <service> element in the request, does not exist for
the location indicated, the server can either return an the location indicated, the server either can return a
<serviceNotImplemented> (Section 13.1) error or can provide an <serviceNotImplemented> (Section 13.1) error or can provide an
alternate service that approximates the desired service for that alternate service that approximates the desired service for that
location. In the latter case, the server MUST include a location. In the latter case, the server MUST include a
<service> element with the alternative service URN. The choice <service> element with the alternative service URN. The choice
of service URN is left to local policy, but the alternate service of service URN is left to local policy, but the alternate service
should be able to satisfy the original service request. should be able to satisfy the original service request.
5.5. Defining the Service Region with the <serviceBoundary> Element 5.5. Defining the Service Region with the <serviceBoundary> Element
A response MAY indicate the region for which the service URL returned 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 would be the same as in the actual query, the so-called service
region_. The service region can be indicated by value or by region. The service region can be indicated by value or by reference
reference (see Section 5.6). If a client moves outside the service (see Section 5.6). If a client moves outside the service area and
area and wishes to obtain current service data, it sends a new query wishes to obtain current service data, it sends a new query with its
with its current location. The service region is described by value current location. The service region is described by value in one or
in one or more <serviceBoundary> elements, each formatted according more <serviceBoundary> elements, each formatted according to a
to a specific location profile, identified by the 'profile' attribute specific location profile, identified by the 'profile' attribute (see
(see Section 12). serviceBoundary elements formatted according to Section 12). <serviceBoundary> elements formatted according to
different location profiles are alternative representations of the different location profiles are alternative representations of the
same area, not additive to one another; this allows a client same area, not additive to one another; this allows a client
understanding only one of the profile types to be sure it has a understanding only one of the profile types to be sure it has a
complete view of the serviceBoundary. Within a serviceBoundary complete view of the serviceBoundary. Within a serviceBoundary
element there may, however, be multiple locations which _are_ element there may, however, be multiple locations which are additive;
additive; this is necessary because some serviceBoundary areas could this is necessary because some <serviceBoundary> areas could not be
not be easily expressed with a single shape or civic location. If easily expressed with a single shape or civic location. If included
included in a response, the <serviceBoundary> element MUST contain at in a response, the <serviceBoundary> element MUST contain at least
least one service boundary that uses the same profile as the request. one service boundary that uses the same profile as the request.
A service boundary is requested by the client, using the A service boundary is requested by the client, using the
'serviceBoundary' attribute in the request with the value set to 'serviceBoundary' attribute in the request with the value set to
"value". "value".
5.6. Service Boundaries by Reference: the <serviceBoundaryReference> 5.6. Service Boundaries by Reference: The <serviceBoundaryReference>
Element Element
Since geodetic service boundaries may contain thousands of points and Since geodetic service boundaries may contain thousands of points and
can thus be quite large, clients may wish to conserve bandwidth by can thus be quite large, clients may wish to conserve bandwidth by
requesting a reference to the service boundary instead of the value requesting a reference to the service boundary instead of the value
described in Section 5.5. The identifier of the service boundary is described in Section 5.5. The identifier of the service boundary is
returned as an attribute of the <serviceBoundaryReference> element, returned as an attribute of the <serviceBoundaryReference> element,
along with a LoST application unique string (see Section 4) along with a LoST application unique string (see Section 4)
identifying the server from where it can be retrieved. The actual identifying the server from where it can be retrieved. The actual
value of the service boundary is then retrieved with the value of the service boundary is then retrieved with the
getServiceBoundary (Section 9) request. getServiceBoundary (Section 9) request.
A reference to a service boundary is requested by the client (using A reference to a service boundary is requested by the client using
the 'serviceBoundary' attribute in the request with the value set to the 'serviceBoundary' attribute in the request with the value set to
"reference"). A LoST server may decide, based on local policy, to "reference". A LoST server may decide, based on local policy, to
return the service boundary per value or to omit the return the service boundary by value or to omit the
<serviceBoundaryReference> element in the response. <serviceBoundaryReference> element in the response.
The identifier is a random token with at least 128 bits of entropy 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 and can be assumed to be globally unique. It uniquely references a
particular boundary. If the boundary changes, a new identifier MUST particular boundary. If the boundary changes, a new identifier MUST
be chosen. Because of these properties, a client receiving a mapping be chosen. Because of these properties, a client receiving a mapping
response can simply check if it already has a copy of the boundary 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 with that identifier. If so, it can skip checking with the server
whether the boundary has been updated. Since service boundaries are whether the boundary has been updated. Since service boundaries are
likely to remain unchanged for extended periods of time, possibly likely to remain unchanged for extended periods of time, possibly
exceeding the normal lifetime of the service URL, this approach exceeding the normal lifetime of the service URL, this approach
avoids unnecessarily refreshing the boundary information just because avoids unnecessarily refreshing the boundary information just because
the remainder of the mapping has become invalid. the remainder of the mapping has become invalid.
5.7. The Service Number: the <serviceNumber> Element 5.7. The Service Number: The <serviceNumber> Element
The service number is returned in the optional <serviceNumber> The service number is returned in the optional <serviceNumber>
element. It contains a string of digits, * and # that a user on a 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 device with a 12-key dial pad could use to reach that particular
service. service.
5.8. Service URLs: the <uri> Element 5.8. Service URLs: The <uri> Element
The response returns the service URLs in one or more <uri> elements. The response returns the service URLs in one or more <uri> elements.
The URLs MUST be absolute URLs. The ordering of the URLs has no The URLs MUST be absolute URLs. The ordering of the URLs has no
particular significance. Each URL scheme MUST only appear at most particular significance. Each URL scheme MUST only appear at most
once, but it is permissible to include both secured and regular once, but it is permissible to include both secured and regular
versions of a protocol, such as both 'http' and 'https' or 'sip' and versions of a protocol, such as both 'http' and 'https' or 'sip' and
'sips'. 'sips'.
6. Path of a Request: the <path> Element 6. Path of a Request: The <path> Element
To prevent loops and to allow tracing of request and response paths, To prevent loops and to allow tracing of request and response paths,
all requests that allow recursion include a <path> element that all requests that allow recursion include a <path> element that
contains one or more <via> elements, each possessing an attribute contains one or more <via> elements, each possessing an attribute
containing a LoST application unique string (see Section 4). The containing a LoST application unique string (see Section 4). The
order of <via> elements corresponds to the order of LoST servers, order of <via> elements corresponds to the order of LoST servers,
i.e., the first <via> element identifies the server that initially i.e., the first <via> element identifies the server that initially
received the request from the client issuing the request. Every received the request from the client issuing the request. Every
server in a recursive query operation is included in the server in a recursive query operation is included in the <path>
<path>element, including the first server to receive it. element, including the first server to receive it.
The server that answers the request instead of forwarding it, such as The server that answers the request instead of forwarding it, such as
the authoritative server, copies the <path> element verbatim into the the authoritative server, copies the <path> element verbatim into the
response. The <path> element is not modified in responses as the response. The <path> element is not modified in responses as the
responses traverses the server chain back to the querying client. responses traverses the server chain back to the querying client.
If a query is answered iteratively, the querier includes all servers If a query is answered iteratively, the querier includes all servers
that it has already contacted. that it has already contacted.
When a cached mapping is returned then the <path> element cached When a cached mapping is returned, then the <path> element cached
together with the mapping is returned. together with the mapping is returned.
The example in Figure 4 indicates that the answer was given to the The example in Figure 4 indicates that the answer was given to the
client by the LoST server at esgw.ueber-110.de.example, which got the client by the LoST server at esgw.ueber-110.de.example, which got the
answer from the (authoritative) LoST server at answer from the (authoritative) LoST server at
polizei.muenchen.de.example. polizei.muenchen.de.example.
7. Identifying the Location Element Used for Mapping: <locationUsed> 7. Identifying the Location Element Used for Mapping: <locationUsed>
Several of the requests can provide one or more <location> elements, Several of the requests can provide one or more <location> elements,
among which the server gets to choose. It is useful for the client among which the server gets to choose. It is useful for the client
to be able to determine which one was actually used in producing the to be able to determine which one was actually used in producing the
result. For that purpose, the <location> tag MUST contain an 'id' result. For that purpose, the <location> tag MUST contain an 'id'
attribute that uniquely identifies the <location> element. The attribute that uniquely identifies the <location> element. The
format of the identifier is left to the client; it could, for format of the identifier is left to the client; it could, for
example, use a hash of the location information. The server returns example, use a hash of the location information. The server returns
the identifier for the <location> element it used in the the identifier for the <location> element it used in the
<locationUsed> tag. See Section 8.3.1 for more details. <locationUsed> tag.
8. Mapping a Location and Service to URLs: <findService> 8. Mapping a Location and Service to URLs: <findService>
8.1. Overview 8.1. Overview
The <findService> query constitutes the core of the LoST The <findService> query constitutes the core of the LoST
functionality, mapping civic or geodetic locations to URLs and functionality, mapping civic or geodetic locations to URLs and
associated data. After giving an example, we enumerate the elements associated data. After giving an example, we enumerate the elements
of the query and response. of the query and response.
skipping to change at page 18, line 11 skipping to change at page 14, line 11
associated with police (urn:service:sos.police) along with a specific associated with police (urn:service:sos.police) along with a specific
civic address (house number 6 on a street named Otto-Hahn-Ring in civic address (house number 6 on a street named Otto-Hahn-Ring in
Munich, Germany). Munich, Germany).
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1" <findService xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true" serviceBoundary="value"> recursive="true" serviceBoundary="value">
<location id="627b8bf819d0bad4d" profile="civic"> <location id="627b8bf819d0bad4d" profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country> <country>DE</country>
<A1>Bavaria</A1> <A1>Bavaria</A1>
<A3>Munich</A3> <A3>Munich</A3>
<A6>Otto-Hahn-Ring</A6> <A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO> <HNO>6</HNO>
<PC>81675</PC> <PC>81675</PC>
</civicAddress> </civicAddress>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
skipping to change at page 18, line 35 skipping to change at page 14, line 35
information related to that service. In the example below, the information related to that service. In the example below, the
server has mapped the location given by the client for a police server has mapped the location given by the client for a police
service to the Muenchen Polizei-Abteilung, instructing the client service to the Muenchen Polizei-Abteilung, instructing the client
that it may contact them via the URIs sip:munich-police@example.com that it may contact them via the URIs sip:munich-police@example.com
and xmpp:munich-police@example.com. The server has also given the and xmpp:munich-police@example.com. The server has also given the
client a civic address boundary (the city of Munich) for this client a civic address boundary (the city of Munich) for this
service. The mapping was last updated on November 1, 2006 by the service. The mapping was last updated on November 1, 2006 by the
authoritative source "polizei.muenchen.de.example" and expires on authoritative source "polizei.muenchen.de.example" and expires on
January 1, 2007. This instructs the client to requery for the January 1, 2007. This instructs the client to requery for the
information if its location changes beyond the given service boundary information if its location changes beyond the given service boundary
(i.e., beyond the city of Munich) or after January 1, 2007. (i.e., beyond the indicated district of Munich) or after January 1,
2007.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="esgw.ueber-110.de.example" source="esgw.ueber-110.de.example"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109"> sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
<displayName xml:lang="de"> <displayName xml:lang="de">
Muenchen Polizei-Abteilung Muenchen Polizei-Abteilung
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary <serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic"> profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country> <country>DE</country>
<A1>Bavaria</A1> <A1>Bavaria</A1>
<A3>Munich</A3> <A3>Munich</A3>
<PC>81675</PC> <PC>81675</PC>
</civicAddress> </civicAddress>
</serviceBoundary> </serviceBoundary>
<uri>sip:munich-police@example.com</uri> <uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber> <serviceNumber>110</serviceNumber>
</mapping> </mapping>
<path> <path>
skipping to change at page 19, line 43 skipping to change at page 15, line 43
</path> </path>
<locationUsed id="627b8bf819d0bad4d"/> <locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse> </findServiceResponse>
Figure 4: A <findServiceResponse> civic address answer Figure 4: A <findServiceResponse> civic address answer
8.3. Components of the <findService> Request 8.3. Components of the <findService> Request
The <findService> request includes attributes and elements that The <findService> request includes attributes and elements that
govern whether the request is handled iteratively or recursively, govern whether the request is handled iteratively or recursively,
whether location validation is performed and which elements may be whether location validation is performed, and which elements may be
contained in the response. contained in the response.
8.3.1. The <location> Element 8.3.1. The <location> Element
The <findService> query communicates location information using one The <findService> query communicates location information using one
or more <location> elements, which MUST conform to a location profile or more <location> elements, which MUST conform to a location profile
(see Section 12). There MUST NOT be more than one location element (see Section 12). There MUST NOT be more than one location element
for each distinct location profile. The order of location elements for each distinct location profile. The order of location elements
is significant; the server uses the first location element where it is significant; the server uses the first location element where it
understands the location profile. understands the location profile.
skipping to change at page 20, line 22 skipping to change at page 16, line 24
LoST can operate in either recursive or iterative mode, on a request- LoST can operate in either recursive or iterative mode, on a request-
by-request basis. In recursive mode, the LoST server initiates by-request basis. In recursive mode, the LoST server initiates
queries on behalf of the requester and returns the result to the queries on behalf of the requester and returns the result to the
requester. requester.
In iterative mode, the server contacted returns a redirection In iterative mode, the server contacted returns a redirection
response indicating the next server to be queried if the server response indicating the next server to be queried if the server
contacted cannot provide an answer itself. contacted cannot provide an answer itself.
For the queries defined in this document, only LoST <findService> and For the queries defined in this document, only the LoST <findService>
<listServicesByLocation> queries can be recursive, as indicated by and <listServicesByLocation> queries can be recursive, as indicated
the 'recursive' attribute. A value of "true" indicates a recursive by the 'recursive' attribute. A value of "true" indicates a
query, with the default being "false" when the attribute is omitted. recursive query, with the default being "false" when the attribute is
Regardless of the attribute, a server MAY always answer a query by omitted. Regardless of the attribute, a server MAY always answer a
providing a LoST application unique string (see Section 4), i.e., query by providing a LoST application unique string (see Section 4),
indirection, however, it MUST NOT recurse if the attribute is i.e., indirection; however, it MUST NOT recurse if the attribute is
"false". "false".
8.3.4. Service Boundary 8.3.4. Service Boundary
LoST <mapping> elements can describe the service boundary either by LoST <mapping> elements can describe the service boundary either by
value or by reference. Returning a service boundary reference is value or by reference. Returning a service boundary reference is
generally more space-efficient for geospatial (polygon) boundaries generally more space-efficient for geospatial (polygon) boundaries
and if the boundaries change rarely, but does incur an additional and if the boundaries change rarely, but does incur an additional
<getServiceBoundary> request. The querier can express a preference <getServiceBoundary> request. The querier can express a preference
for one or the other modality with the 'serviceBoundary' attribute in for one or the other modality with the 'serviceBoundary' attribute in
skipping to change at page 22, line 18 skipping to change at page 18, line 18
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example" source="authoritative.example"
sourceId="4db898df52b84edfa9b6445ea8a0328e"> sourceId="4db898df52b84edfa9b6445ea8a0328e">
<displayName xml:lang="de"> <displayName xml:lang="de">
Muenchen Polizei-Abteilung Muenchen Polizei-Abteilung
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="civic"> <serviceBoundary profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country> <country>DE</country>
<A1>Bavaria</A1> <A1>Bavaria</A1>
<A3>Munich</A3> <A3>Munich</A3>
<PC>81675</PC> <PC>81675</PC>
</civicAddress> </civicAddress>
</serviceBoundary> </serviceBoundary>
<uri>sip:munich-police@example.com</uri> <uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber> <serviceNumber>110</serviceNumber>
</mapping> </mapping>
<locationValidation> <locationValidation>
skipping to change at page 23, line 5 skipping to change at page 19, line 5
8.4. Components of the Mapping Response <findServiceResponse> 8.4. Components of the Mapping Response <findServiceResponse>
8.4.1. Overview 8.4.1. Overview
Mapping responses consist of the <mapping> element (Section 5) Mapping responses consist of the <mapping> element (Section 5)
describing the mapping itself, possibly followed by warnings describing the mapping itself, possibly followed by warnings
(Section 13.2), location validation information (Section 8.4.2), and (Section 13.2), location validation information (Section 8.4.2), and
an indication of the path (Section 6) the response has taken. an indication of the path (Section 6) the response has taken.
8.4.2. Civic Address Validation: the <locationValidation> Element 8.4.2. Civic Address Validation: The <locationValidation> Element
A server can indicate in its response which civic address elements it A server can indicate in its response which civic address elements it
has recognized as valid, which ones it has ignored and which ones it has recognized as valid, which ones it has ignored, and which ones it
has checked and found to be invalid. The server SHOULD include this has checked and found to be invalid. The server SHOULD include this
information if the 'validateLocation' attribute in the request was information if the 'validateLocation' attribute in the request was
true but local policy at the server may allow this information to be true, but local policy at the server may allow this information to be
omitted. Each element contains a list of tokens separated by white omitted. Each element contains a list of tokens separated by
space, enumerating the civic location labels used in child elements whitespace, enumerating the civic location labels used in child
of the <civicAddress> element. The <valid> element enumerates those elements of the <civicAddress> element. The <valid> element
civic address elements that have been recognized as valid by the LoST enumerates those civic address elements that have been recognized as
server and that have been used to determine the mapping. The valid by the LoST server and that have been used to determine the
<unchecked> elements enumerates the civic address elements that the mapping. The <unchecked> elements enumerates the civic address
server did not check and that were not used in determining the elements that the server did not check and that were not used in
response. The <invalid> element enumerate civic address elements determining the response. The <invalid> element enumerate civic
that the server attempted to check, but that did not match the other address elements that the server attempted to check, but that did not
civic address elements found in the <valid> list. Civic location match the other civic address elements found in the <valid> list.
tokens that are neither listed in the <valid>, the <invalid> and the Civic location tokens that are not listed in either the <valid>,
<unchecked> element belong to the class of unchecked tokens. <invalid>, or <unchecked> element belong to the class of unchecked
tokens.
Note that the same address can yield different responses if parts of Note that the same address can yield different responses if parts of
the civic address contradict each other. For example, if the postal the civic address contradict each other. For example, if the postal
code does not match the city, local server policy determines whether code does not match the city, local server policy determines whether
the postal code or the city is considered valid. The mapping the postal code or the city is considered valid. The mapping
naturally corresponds to the valid elements. naturally corresponds to the valid elements.
The example shown in Figure 5 and in Figure 6 indicates that the The example shown in Figure 5 and in Figure 6 indicates that the
tokens 'country', 'A1', 'A3', and 'A6' have been validated by the tokens 'country', 'A1', 'A3', and 'A6' have been validated by the
LoST server. The server considered the postal code 81675 in the <PC> LoST server. The server considered the postal code 81675 in the <PC>
skipping to change at page 24, line 13 skipping to change at page 19, line 46
the class of unchecked location tokens. the class of unchecked location tokens.
9. Retrieving the Service Boundary via <getServiceBoundary> 9. Retrieving the Service Boundary via <getServiceBoundary>
As discussed in Section 5.5, the <findServiceResponse> can return a As discussed in Section 5.5, the <findServiceResponse> can return a
globally unique identifier in the 'serviceBoundary' attribute that globally unique identifier in the 'serviceBoundary' attribute that
can be used to retrieve the service boundary, rather than returning can be used to retrieve the service boundary, rather than returning
the boundary by value. This is shown in the example in Figure 7 and the boundary by value. This is shown in the example in Figure 7 and
Figure 8. The client can then retrieve the boundary using the Figure 8. The client can then retrieve the boundary using the
<getServiceBoundary> request and obtains the boundary in the <getServiceBoundary> request and obtains the boundary in the
<getServiceBoundaryResponse>, illustrated in the example in Figure 9. <getServiceBoundaryResponse>, illustrated in the example in Figure 9
The client issues the request to the server identified in the and Figure 10. The client issues the request to the server
'server' attribute of the <serviceBoundaryReference> element. These identified in the 'server' attribute of the
requests are always directed to the authoritative server and do not <serviceBoundaryReference> element. These requests are always
recurse. directed to the authoritative server and do not recurse.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findService <findService
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" xmlns:p2="http://www.opengis.net/gml"
recursive="true" recursive="true"
serviceBoundary="reference"> serviceBoundary="reference">
<location id="6020688f1ce1896d" profile="geodetic-2d"> <location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos> <p2:pos>37.775 -122.422</p2:pos>
skipping to change at page 25, line 32 skipping to change at page 21, line 4
</mapping> </mapping>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="6020688f1ce1896d"/> <locationUsed id="6020688f1ce1896d"/>
</findServiceResponse> </findServiceResponse>
Figure 8: <findServiceResponse> message with service boundary Figure 8: <findServiceResponse> message with service boundary
reference reference
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1" <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
key="7214148E0433AFE2FA2D48003D31172E"/> key="7214148E0433AFE2FA2D48003D31172E"/>
Figure 9: Requesting a service boundary with <getServiceBoundary> Figure 9: Requesting a service boundary with <getServiceBoundary>
The <getServiceBoundary> request may also be used to retrieve service
boundaries that are expressed as civic addresses, as illustrated in
Figure 10.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundaryResponse <getServiceBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1"> xmlns="urn:ietf:params:xml:ns:lost1">
<serviceBoundary profile="civic"> <serviceBoundary profile="geodetic-2d">
<civicAddress <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <p2:exterior>
<country>US</country> <p2:LinearRing>
<A1>New York</A1> <p2:pos>37.775 -122.4194</p2:pos>
<A3>New York</A3> <p2:pos>37.555 -122.4194</p2:pos>
</civicAddress> <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> </serviceBoundary>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
</getServiceBoundaryResponse> </getServiceBoundaryResponse>
Figure 10: Civic Address Service Boundary Response Figure 10: Geodetic service boundary response
10. List Services: <listServices> 10. List Services: <listServices>
A LoST client can ask a LoST server for the list of services that it A LoST client can ask a LoST server for the list of services that it
understands, primarily for diagnostic purposes. The query does not understands, primarily for diagnostic purposes. The query does not
contain location information, as it simply provides an indication of contain location information, as it simply provides an indication of
which services the server can look up, not whether a particular which services the server can look up, not whether a particular
service is offered for a particular area. Typically, only top-level service is offered for a particular area. Typically, only top-level
services are included in the answer, implying support for all sub- services are included in the answer, implying support for all sub-
services. Since the query is answered by the queried server, there services. Since the query is answered by the queried server, there
is no notion of recursion or indirection and no path indication. The is no notion of recursion or indirection. The
<listServicesByLocation> (Section 11) query below can be used to find <listServicesByLocation> (Section 11) query below can be used to find
out whether a particular service is offered for a specific location. out whether a particular service is offered for a specific location.
An example request and response are shown in Figure 11. An example request and response are shown in Figure 11.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServices <listServices
xmlns="urn:ietf:params:xml:ns:lost1"> xmlns="urn:ietf:params:xml:ns:lost1">
<service>urn:service:sos</service> <service>urn:service:sos</service>
</listServices> </listServices>
skipping to change at page 27, line 40 skipping to change at page 22, line 26
<serviceList> <serviceList>
urn:service:sos.ambulance urn:service:sos.ambulance
urn:service:sos.animal-control urn:service:sos.animal-control
urn:service:sos.fire urn:service:sos.fire
urn:service:sos.gas urn:service:sos.gas
urn:service:sos.mountain urn:service:sos.mountain
urn:service:sos.marine urn:service:sos.marine
urn:service:sos.physician urn:service:sos.physician
urn:service:sos.poison urn:service:sos.poison
urn:service:sos.police urn:service:sos.police
urn:service:sos.suicide
</serviceList> </serviceList>
<path> <path>
<via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
</listServicesResponse> </listServicesResponse>
Figure 12: Example of <ListServiceResponse> Figure 12: Example of <ListServicesResponse>
11. List Services By Location: <listServicesByLocation> 11. List Services By Location: <listServicesByLocation>
A LoST client can ask a LoST server for the list of services it knows A LoST client can ask a LoST server for the list of services it knows
about for a particular area. The <listServicesByLocation> query about for a particular area. The <listServicesByLocation> query
contains one or more <location> elements, each from a different contains one or more <location> elements, each from a different
location profile (Section 12), and may contain the <service> element. location profile (Section 12), and may contain the <service> element.
As for <findService>, the server selects the first location element As for <findService>, the server selects the first location element
that has a profile the server understands and it can operate either that has a profile the server understands and it can operate either
recursively or iteratively; <via> elements track the progress of the recursively or iteratively; <via> elements track the progress of the
request. The query indicates the services that the server can request. The query indicates the services that the server can
enumerate from within the forest structure of which it is a part. enumerate from within the forest structure of which it is a part.
Because LoST does not presume a single, overarching organization of Because LoST does not presume a single, overarching organization of
all potential service types, there may be services available within a all potential service types, there may be services available within a
geographic area which could be described by other LoST servers geographic area that could be described by other LoST servers
connected to other forest structures. As an example, the emergency connected to other forest structures. As an example, the emergency
services forest for a region may be distinct from the forests that services forest for a region may be distinct from the forests that
locate commercial services within the same region locate commercial services within the same region.
If the query contains the <service> element, the LoST server returns If the query contains the <service> element, the LoST server returns
only immediate child services of the queried service that are only immediate child services of the queried service that are
available for the provided location. If the <service> element is available for the provided location. If the <service> element is
absent, the LoST service returns all top-level services available for absent, the LoST service returns all top-level services available for
the provided location that it knows about. the provided location that it knows about.
A server responds to this query with a A server responds to this query with a
<listServicesByLocationResponse> response. This response MAY contain <listServicesByLocationResponse> response. This response MAY contain
<via> elements (see Section 6) and MUST contain a <serviceList> <via> elements (see Section 6) and MUST contain a <serviceList>
skipping to change at page 29, line 17 skipping to change at page 24, line 17
<serviceList> <serviceList>
urn:service:sos.ambulance urn:service:sos.ambulance
urn:service:sos.animal-control urn:service:sos.animal-control
urn:service:sos.fire urn:service:sos.fire
urn:service:sos.gas urn:service:sos.gas
urn:service:sos.mountain urn:service:sos.mountain
urn:service:sos.marine urn:service:sos.marine
urn:service:sos.physician urn:service:sos.physician
urn:service:sos.poison urn:service:sos.poison
urn:service:sos.police urn:service:sos.police
urn:service:sos.suicide
</serviceList> </serviceList>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="3e19dfb3b9828c3"/> <locationUsed id="3e19dfb3b9828c3"/>
</listServicesByLocationResponse> </listServicesByLocationResponse>
Figure 14: Example of <ListServices> response Figure 14: Example of <ListServicesByLocationResponse> response
12. Location Profiles 12. Location Profiles
LoST uses location information in <location> elements in requests and LoST uses location information in <location> elements in requests and
<serviceBoundary> elements in responses. Such location information <serviceBoundary> elements in responses. Such location information
may be expressed in a variety of ways. This variety can cause may be expressed in a variety of ways. This variety can cause
interoperability problems where a request or response contains interoperability problems where a request or response contains
location information in a format not understood by the server or the location information in a format not understood by the server or the
client, respectively. To achieve interoperability, this document client, respectively. To achieve interoperability, this document
defines two mandatory-to-implement baseline location profiles to defines two mandatory-to-implement baseline location profiles to
skipping to change at page 30, line 19 skipping to change at page 24, line 41
may be expressed in a variety of ways. This variety can cause may be expressed in a variety of ways. This variety can cause
interoperability problems where a request or response contains interoperability problems where a request or response contains
location information in a format not understood by the server or the location information in a format not understood by the server or the
client, respectively. To achieve interoperability, this document client, respectively. To achieve interoperability, this document
defines two mandatory-to-implement baseline location profiles to defines two mandatory-to-implement baseline location profiles to
define the manner in which location information is transmitted. It define the manner in which location information is transmitted. It
is possible to standardize other profiles in the future. The is possible to standardize other profiles in the future. The
baseline profiles are: baseline profiles are:
geodetic-2d: geodetic-2d:
a profile for two-dimensional geodetic location information, as a profile for two-dimensional geodetic location information, as
described in Section 12.2; described in Section 12.2;.
civic: civic:
a profile consisting of civic address location information, as a profile consisting of civic address location information, as
described in Section 12.3. described in Section 12.3.
Requests and responses containing <location> or <serviceBoundary> Requests and responses containing <location> or <serviceBoundary>
elements MUST contain location information in exactly one of the two elements MUST contain location information in exactly one of the two
baseline profiles, in addition to zero or more additional profiles. baseline profiles, in addition to zero or more additional profiles.
The ordering of location information indicates a preference on the The ordering of location information indicates a preference on the
part of the sender. part of the sender.
Standards action is required for defining new profiles. A location Standards action is required for defining new profiles. A location
skipping to change at page 30, line 37 skipping to change at page 25, line 14
Requests and responses containing <location> or <serviceBoundary> Requests and responses containing <location> or <serviceBoundary>
elements MUST contain location information in exactly one of the two elements MUST contain location information in exactly one of the two
baseline profiles, in addition to zero or more additional profiles. baseline profiles, in addition to zero or more additional profiles.
The ordering of location information indicates a preference on the The ordering of location information indicates a preference on the
part of the sender. part of the sender.
Standards action is required for defining new profiles. A location Standards action is required for defining new profiles. A location
profile MUST define: profile MUST define:
1. The token identifying it in the LoST location profile registry; 1. The token identifying it in the LoST location profile registry.
2. The formal definition of the XML to be used in requests, i.e., an 2. The formal definition of the XML to be used in requests, i.e., an
enumeration and definition of the XML child elements of the enumeration and definition of the XML child elements of the
<location> element; <location> element.
3. The formal definition of the XML to be used in responses, i.e., 3. The formal definition of the XML to be used in responses, i.e.,
an enumeration and definition of the XML child elements of the an enumeration and definition of the XML child elements of the
<serviceBoundary> element; <serviceBoundary> element.
4. The declaration of whether geodetic-2d or civic is to be used as 4. The declaration of whether geodetic-2d or civic is to be used as
the baseline profile. It is necessary to explicitly declare the the baseline profile. It is necessary to explicitly declare the
baseline profile as future profiles may be combinations of baseline profile as future profiles may be combinations of
geodetic and civic location information. geodetic and civic location information.
12.1. Location Profile Usage 12.1. Location Profile Usage
A location profile is identified by a token in an IANA-maintained A location profile is identified by a token in an IANA-maintained
registry (Section 17.5). Clients send location information compliant registry (Section 17.5). Clients send location information compliant
with a location profile, and servers respond with location with a location profile, and servers respond with location
information compliant with that same location profile. information compliant with that same location profile.
When a LoST client sends a <findService> request that provides When a LoST client sends a <findService> request that provides
location information, it includes one or more <location> elements. A location information, it includes one or more <location> elements. A
<location> element carries an optional 'profile' attribute that <location> element carries an optional 'profile' attribute that
indicates the location format of the child elements. A client may indicates the location format of the child elements. A client may
obtain location information that does not conform to a profile it obtain location information that does not conform to a profile it
recognizes or it may not have the capability to map XML to profiles. recognizes, or it may not have the capability to map XML to profiles.
In that case, a client MAY omit the profile attribute and the server In that case, a client MAY omit the profile attribute and the server
should interpret the XML location data to the best of its ability, should interpret the XML location data to the best of its ability,
returning a "locationProfileUnrecognized" error if it is unable to do returning a "locationProfileUnrecognized" error if it is unable to do
so. so.
The concept of location profiles are described in Section 12. With The concept of location profiles is described in Section 12. With
the ability to specify more than one <location> element the client is the ability to specify more than one <location> element, the client
able to convey location information for multiple location profiles in is able to convey location information for multiple location profiles
the same request. in the same request.
When a LoST server sends a response that contains location When a LoST server sends a response that contains location
information, it uses the <serviceBoundary> elements much like the information, it uses the <serviceBoundary> elements much like the
client uses the <location> elements. Each <serviceBoundary> element client uses the <location> elements. Each <serviceBoundary> element
contains location information conforming to the location profile contains location information conforming to the location profile
specified in the 'profile' attribute. A response MAY contain specified in the 'profile' attribute. A response MAY contain
multiple mappings or boundaries for the different <location> multiple mappings or boundaries for the different <location>
elements, subject to the restrictions below. elements, subject to the restrictions below.
Using the location profiles defined in this document, the following Using the location profiles defined in this document, the following
skipping to change at page 32, line 29 skipping to change at page 27, line 11
8. If a server receives a request that only contains location 8. If a server receives a request that only contains location
information using profiles it does not understand, the server information using profiles it does not understand, the server
responds with a <locationProfileError> (Section 13.1). responds with a <locationProfileError> (Section 13.1).
9. The <serviceBoundary> element MUST use the same location profile 9. The <serviceBoundary> element MUST use the same location profile
that was used to retrieve the answer and indicates which profile that was used to retrieve the answer and indicates which profile
has been used with the 'profile' attribute. has been used with the 'profile' attribute.
These rules enable the use of location profiles not yet specified, These rules enable the use of location profiles not yet specified,
while ensuring baseline interoperability. Take, for example, this while ensuring baseline interoperability. Take, for example, this
scenario. Client X has had its firmware upgraded to support the scenario illustrated in Figure 15 and 16. Client X has had its
'not-yet-standardized-prism-profile' location profile. Client X firmware upgraded to support the 'not-yet-standardized-prism-profile'
sends location information to Server Y, which does not understand the location profile. Client X sends location information to Server Y,
'not-yet-standardized-prism-profile' location profile. If Client X which does not understand the 'not-yet-standardized-prism-profile'
also sends location information using the geodetic-2D baseline location profile. If Client X also sends location information using
profile, then Server Y will still be able to understand the request the geodetic-2D baseline profile, then Server Y will still be able to
and provide an understandable response, though with location understand the request and provide an understandable response, though
information that might not be as precise or expressive as desired. with location information that might not be as precise or expressive
This is possible because both Client X and Server Y understand the as desired. This is possible because both Client X and Server Y
baseline profile. understand the baseline profile.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findService <findService
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
recursive="true" recursive="true"
serviceBoundary="value"> serviceBoundary="value">
<location id="ABC 123" <location id="ABC 123"
profile="not-yet-standardized-prism-profile"> profile="not-yet-standardized-prism-profile">
skipping to change at page 34, line 37 skipping to change at page 29, line 37
</p2:exterior> </p2:exterior>
</p2:Polygon> </p2:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:nypd@example.com</uri> <uri>sip:nypd@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="6020688f1ce1896d"/> <locationUsed id="DEF 345"/>
</findServiceResponse> </findServiceResponse>
Figure 16: Example of a <findServiceResponse> message with baseline Figure 16: Example of a <findServiceResponse> message with baseline
profile interoperability profile interoperability
12.2. Two Dimensional Geodetic Profile 12.2. Two-Dimensional Geodetic Profile
The "geodetic-2d" location profile is identified by "geodetic-2d". The "geodetic-2d" location profile is identified by the token
Clients and servers use this profile by placing the following "geodetic-2d". Clients and servers use this profile by placing the
location shapes into the <serviceBoundary> or into the <location> following location shapes into the <serviceBoundary> or into the
element (unless indicated otherwise): <location> element (unless indicated otherwise):
Point: Point:
The <Point> element is described in Section 5.2.1 of [13]. The <Point> element is described in Section 5.2.1 of [13].
Section 5.2.1 of [13] shows also the specification of a <Point> Section 5.2.1 of [13] shows also the specification of a <Point>
with either a two dimensional position (latitude and longitude) or with either a two-dimensional position (latitude and longitude) or
three dimensional position (latitude, longitude, and altitude). A three-dimensional position (latitude, longitude, and altitude). A
client MAY use the three dimensional position, and servers MAY client MAY use the three-dimensional position, and servers MAY
interpret a three dimensional position as a two dimensional interpret a three-dimensional position as a two-dimensional
position by ignoring the altitude value. A <Point> element is not position by ignoring the altitude value. A <Point> element is not
placed into a <serviceBoundary> element. placed into a <serviceBoundary> element.
Polygon: Polygon:
The <Polygon> element is described in Section 5.2.2 of [13]. The The <Polygon> element is described in Section 5.2.2 of [13]. The
restriction to 16 points for a polygon contained in Section 7.2.2 restriction to 16 points for a polygon contained in Section 7.2.2
of [12] is not applicable to this document. of [12] is not applicable to this document.
Circle: Circle:
The <Circle> element is described in Section 5.2.3 of [13]. The <Circle> element is described in Section 5.2.3 of [13].
Ellipse: Ellipse:
The <Ellipse> element is described in Section 5.2.4 of [13]. The <Ellipse> element is described in Section 5.2.4 of [13].
ArcBand: ArcBand:
The <ArcBand> element is described in Section 5.2.5 of [13]. The <ArcBand> element is described in Section 5.2.5 of [13].
When a client uses a <Polygon>, <Circle>, <Ellipse> or <ArcBand> When a client uses a <Polygon>, <Circle>, <Ellipse>, or <ArcBand>
element within the <location> element, it is indicating that it will element within the <location> element, it is indicating that it will
be satisfied by query results appropriate to any portion of the be satisfied by query results appropriate to any portion of the
shape. It is left to the server to select an appropriate matching shape. It is left to the server to select an appropriate matching
algorithm. A server MAY return multiple <mapping> elements if the algorithm. A server MAY return multiple <mapping> elements if the
shape extends across multiple service areas. Servers are not shape extends across multiple service areas. Servers are not
required to return all possible <mapping> elements to avoid denial of required to return all possible <mapping> elements to avoid denial-
service attacks in which clients present queries that span a very of-service attacks in which clients present queries that span a very
large number service boundaries (e.g. presenting a shape covering all large number of service boundaries (e.g., presenting a shape covering
of the United States). all of the United States).
In the case where the server does not return multiple <mapping> In the case where the server does not return multiple <mapping>
elements, but the shape extends across a service boundary, it is elements, but the shape extends across a service boundary, it is
possible that the matching algorithm selected by the LoST server will possible that the matching algorithm selected by the LoST server will
return results that match a portion of the shape but do not match return results that match a portion of the shape but do not match
those specific to a particular point. A client may always select a those specific to a particular point. A client may always select a
point from within the shape to avoid this condition. The cases where point from within the shape to avoid this condition. The cases where
it does not are generally those where it knows its own position only it does not are generally those where it knows its own position only
within the shape given. In emergency service use cases, that may within the shape given. In emergency service use cases, that may
result in the PSAP contacted at the URI provided by LoST being result in the PSAP contacted at the URI provided by LoST being
required to forward a call to one of its neighbors; this is an required to forward a call to one of its neighbors; this is an
expected part of the overall emergency response system. In non- expected part of the overall emergency response system. In non-
emergency service use cases, the service deployment model should take emergency service use cases, the service deployment model should take
into account this issue as part of the provisioning model, as the into account this issue as part of the provisioning model, as the
combination of the data in the LoST server and the algorithm used for combination of the data in the LoST server and the algorithm used for
mapping determine which contact URIs are returned when shapes are mapping determine which contact URIs are returned when shapes are
used which overlap multiple service areas. used that overlap multiple service areas.
As a general guideline, any deployed matching algorithm should ensure As a general guideline, any deployed matching algorithm should ensure
that the algorithm used does not needlessly return NULL results if that the algorithm used does not needlessly return no results if
there are valid results for any portion of the shape. If an there are valid results for any portion of the shape. If an
authoritative server receives a query for which the area in the query authoritative server receives a query for which the area in the query
overlaps the area for which the server has mapping information, then overlaps the area for which the server has mapping information, then
it MUST return either a mapping whose coverage area intersects the it MUST return either a mapping whose coverage area intersects the
query area or a redirect to another server whose coverage area is a query area or a redirect to another server whose coverage area is a
subset of the server's coverage area. subset of the server's coverage area.
When geodetic location information of this location profile is placed When geodetic location information of this location profile is placed
in the <serviceBoundary> element then the elements with geospatial in the <serviceBoundary> element, then the elements with geospatial
coordinates are alternative descriptions of the same service region, coordinates are alternative descriptions of the same service region,
not additive geometries. not additive geometries.
12.3. Basic Civic Profile 12.3. Basic Civic Profile
The basic-civic location profile is identified by the token 'civic'. The basic civic location profile is identified by the token 'civic'.
Clients use this profile by placing a <civicAddress> element, defined Clients use this profile by placing a <civicAddress> element, defined
in [10], within the <location> element. in [10], within the <location> element.
Servers use this profile by placing a <civicAddress> element, defined Servers use this profile by placing a <civicAddress> element, defined
in [10], within the <serviceBoundary> element. in [10], within the <serviceBoundary> element.
A response MAY contain more than one <serviceBoundary> element with A response MAY contain more than one <serviceBoundary> element with
profile 'civic'. Each <serviceBoundary> element describes a set of profile 'civic'. Each <serviceBoundary> element describes a set of
civic addresses that fall within the service boundary, namely all civic addresses that fall within the service boundary, namely, all
addresses that textually match the civic address elements provided, addresses that textually match the civic address elements provided,
regardless of the value of other address elements. A location falls regardless of the value of other address elements. A location falls
within the mapping's service boundary if it matches any of the within the mapping's service boundary if it matches any of the
<serviceBoundary> elements. Hence, a response may contain multiple <serviceBoundary> elements. Hence, a response may contain multiple
<serviceBoundary> elements with civic and/or geodetic location <serviceBoundary> elements with civic and/or geodetic location
profiles. profiles.
13. Errors, Warnings, and Redirects 13. Errors, Warnings, and Redirects
When a LoST server cannot fulfill a request completely, it can return When a LoST server cannot fulfill a request completely, it can return
either an error or a warning, depending on the severity of the either an error or a warning, depending on the severity of the
problem. It returns an error element if no useful response can be problem. It returns an <errors> element if no useful response can be
returned for the query. It returns a <warnings> element as part of returned for the query. It returns a <warnings> element as part of
another response element if it was able to respond in part, but the another response element if it was able to respond in part, but the
response may not be quite what the client had desired. For both response may not be quite what the client had desired. For both
elements, the 'source' attribute names the server that originally elements, the 'source' attribute names the server that originally
generated the error or warning, such as the authoritative server. generated the error or warning, such as the authoritative server.
Unless otherwise noted, all elements below can be either an error or Unless otherwise noted, all elements below can be either an error or
a warning, depending on whether a default response, such as a a warning, depending on whether a default response, such as a
mapping, is included. mapping, is included.
13.1. Errors 13.1. Errors
LoST defines a pattern for errors, defined as <errors> elements in LoST defines a pattern for errors, defined as <errors> elements in
the Relax NG schema. This pattern defines a 'message' attribute the Relax NG schema. This pattern defines a 'message' attribute
containing human readable text and an 'xml:lang' attribute denoting containing human-readable text and an 'xml:lang' attribute denoting
the language of the human readable text. One or more such error the language of the human-readable text. One or more such error
elements are contained in the <errors> element. elements are contained in the <errors> element.
The following errors follow this basic pattern: The following errors follow this basic pattern:
badRequest badRequest
The server could not parse or otherwise understand a request, The server could not parse or otherwise understand a request,
e.g., because the XML was malformed. e.g., because the XML was malformed.
forbidden forbidden
The server refused to send an answer. This generally only occurs The server refused to send an answer. This generally only occurs
for recursive queries, namely if the client tried to contact the for recursive queries, namely, if the client tried to contact the
authoritative server and was refused. authoritative server and was refused.
internalError internalError
The server could not satisfy a request due to misconfiguration or The server could not satisfy a request due to misconfiguration or
other operational and non-protocol related reasons. other operational and non-protocol-related reasons.
locationProfileUnrecognized locationProfileUnrecognized
None of the profiles in the request were recognized by the server None of the profiles in the request were recognized by the server
(see Section 12). (see Section 12).
locationInvalid locationInvalid
The geodetic or civic location in the request was invalid. For The geodetic or civic location in the request was invalid. For
example, the longitude or latitude values fall outside the example, the longitude or latitude values fall outside the
acceptable ranges. acceptable ranges.
SRSInvalid SRSInvalid
The spatial reference system (SRS) contained in the location The spatial reference system (SRS) contained in the location
element was not recognized or does not match the location profile. element was not recognized or does not match the location profile.
loop loop
During a recursive query, the server was about to visit a server During a recursive query, the server was about to visit a server
that was already in the server list in the <path> element, that was already in the server list in the <path> element,
indicating a request loop. indicating a request loop.
notFound notFound
The server could not find an answer to the query. The server could not find an answer to the query.
serverError serverError
An answer was received from another LoST server, but it could not An answer was received from another LoST server, but it could not
be parsed or otherwise understood. This error occurs only for be parsed or otherwise understood. This error occurs only for
recursive queries. recursive queries.
serverTimeout serverTimeout
A time out occurred before an answer was received. A time out occurred before an answer was received.
serviceNotImplemented serviceNotImplemented
The requested service URN is not implemented and no substitution The requested service URN is not implemented and no substitution
was available. was available.
An example is below: An example is below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1" <errors xmlns="urn:ietf:params:xml:ns:lost1"
source="resolver.example"> source="resolver.example">
<internalError message="Software bug." xml:lang="en"/> <internalError message="Software bug." xml:lang="en"/>
</errors> </errors>
skipping to change at page 39, line 11 skipping to change at page 33, line 37
was available. was available.
An example is below: An example is below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1" <errors xmlns="urn:ietf:params:xml:ns:lost1"
source="resolver.example"> source="resolver.example">
<internalError message="Software bug." xml:lang="en"/> <internalError message="Software bug." xml:lang="en"/>
</errors> </errors>
Figure 17: Example of an error resonse Figure 17: Example of an error response
13.2. Warnings 13.2. Warnings
A response MAY contain zero or more warnings. This pattern defines a A response MAY contain zero or more warnings. This pattern defines a
'message' attribute containing human readable text and an 'xml:lang' 'message' attribute containing human-readable text and an 'xml:lang'
attribute denoting the language of the human readable text. One or attribute denoting the language of the human-readable text. One or
more such warning elements are contained in the <warnings> element. more such warning elements are contained in the <warnings> element.
To provide human readable text in an appropriate language the HTTP To provide human-readable text in an appropriate language, the HTTP
content negotiation capabilities (see Section 14) MAY be utilized by content negotiation capabilities (see Section 14) MAY be utilized by
a server. a server.
This version of the specification defines the following warnings: This version of the specification defines the following warnings:
locationValidationUnavailable locationValidationUnavailable
The <locationValidationUnavailable> element MAY be returned when a The <locationValidationUnavailable> element MAY be returned when a
server wishes to notify a client that it cannot fulfill a location server wishes to notify a client that it cannot fulfill a location
validation request. This warning allows a server to return validation request. This warning allows a server to return
mapping information while signalling this exception state. mapping information while signaling this exception state.
serviceSubstitution serviceSubstitution
The <serviceSubstitution> element MAY be returned when a server The <serviceSubstitution> element MAY be returned when a server
was not able to fulfill a <findService> request for a given was not able to fulfill a <findService> request for a given
service URN. For example, a <findService> request with the service URN. For example, a <findService> request with the
'urn:service:sos.police' service URN for a location in Uruguay may 'urn:service:sos.police' service URN for a location in Uruguay may
cause the LoST service to return a mapping for the cause the LoST service to return a mapping for the
'urn:service:sos' service URN since Uruguay does not make use of 'urn:service:sos' service URN since Uruguay does not make use of
the sub-services police, fire and ambulance. If this warning is the sub-services police, fire, and ambulance. If this warning is
returned then the <service> element in the response provides returned, then the <service> element in the response provides
information about the service URN that refers to the mapping. information about the service URN that refers to the mapping.
defaultMappingReturned defaultMappingReturned
The <defaultMappingReturned> element MAY be returned when a server The <defaultMappingReturned> element MAY be returned when a server
was not able to fulfill a <findService> request for a given was not able to fulfill a <findService> request for a given
location but is able to respond with a default URI. For example, location but is able to respond with a default URI. For example,
a nearby PSAP may be returned. a nearby PSAP may be returned.
An example of a warning is shown below: An example of a warning is shown below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/"> xmlns:p2="http://www.opengis.net/">
skipping to change at page 40, line 31 skipping to change at page 35, line 33
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing> </p2:LinearRing>
</p2:exterior> </p2:exterior>
</p2:Polygon> </p2:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:nypd@example.com</uri> <uri>sip:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping> </mapping>
<warnings source="authoritative.example"> <warnings source="authoritative.example">
<defaultMappingReturned <defaultMappingReturned
message="Unable to determine PSAP for the given location; message="Unable to determine PSAP for the given location;
using default PSAP" using default PSAP"
xml:lang="en"/> xml:lang="en"/>
</warnings> </warnings>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 18: Example of an warning resonse Figure 18: Example of a warning response
13.3. Redirects 13.3. Redirects
A LoST server can respond indicating that the querier should redirect A LoST server can respond indicating that the querier should redirect
the query to another server, using the <redirect> element. The the query to another server, using the <redirect> element. The
element includes a 'target' attribute indicating the LoST application element includes a 'target' attribute indicating the LoST application
unique string (see Section 4) that the client SHOULD be contacting unique string (see Section 4) that the client SHOULD be contacting
next, as well as the 'source' attribute indicating the server that next, as well as the 'source' attribute indicating the server that
generated the redirect response and a 'message' attribute explaining generated the redirect response and a 'message' attribute explaining
the reason for the redirect response. During a recursive query, a the reason for the redirect response. During a recursive query, a
server receiving a <redirect> response can decide whether it wants to server receiving a <redirect> response can decide whether it wants to
follow the redirection or simply return the response to its upstream follow the redirection or simply return the response to its upstream
querier. The "expires" value in the response returned by the server querier. The "expires" value in the response returned by the server
handling the redirected query indicates the earliest time at which a handling the redirected query indicates the earliest time at which a
new query might be needed (see section 5.2). The query for the same new query might be needed (see Section 5.2). The query for the same
tuple of location and service SHOULD NOT be directed to the server tuple of location and service SHOULD NOT be directed to the server
which gave redirect prior to that time. that gave redirect prior to that time.
An example is below: An example is below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<redirect xmlns="urn:ietf:params:xml:ns:lost1" <redirect xmlns="urn:ietf:params:xml:ns:lost1"
target="eastpsap.example" target="eastpsap.example"
source="westpsap.example" source="westpsap.example"
message="We have temporarily failed over." xml:lang="en"/> message="We have temporarily failed over." xml:lang="en"/>
Figure 19: Example of a redirect response Figure 19: Example of a redirect response
14. LoST Transport: HTTP 14. LoST Transport: HTTP
LoST needs an underlying protocol transport mechanisms to carry LoST needs an underlying protocol transport mechanism to carry
requests and responses. This document defines the use of LoST over requests and responses. This document defines the use of LoST over
HTTP and LoST over HTTP-over-TLS. Client and server developers are HTTP and LoST over HTTP-over-TLS. Client and server developers are
reminded that full support of RFC 2616 HTTP facilities is expected. reminded that full support of RFC 2616 HTTP facilities is expected.
If LoST clients or servers re-implement HTTP, rather than using If LoST clients or servers re-implement HTTP, rather than using
available servers or client code as a base, careful attention must be available servers or client code as a base, careful attention must be
paid to full interoperability. Other transport mechanisms are left paid to full interoperability. Other transport mechanisms are left
to future documents. The available transport mechanisms are to future documents. The available transport mechanisms are
determined through the use of the LoST U-NAPTR application. In determined through the use of the LoST U-NAPTR application. In
protocols that support content type indication, LoST uses the media protocols that support content type indication, LoST uses the media
type application/lost+xml. type application/lost+xml.
When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP
POST method. The HTTP request MUST use the Cache-Control response POST method. The HTTP request MUST use the Cache-Control response
directive "no-cache" to HTTP-level caching even by caches that have directive "no-cache" to disable HTTP-level caching even by caches
been configured to return stale responses to client requests. that have been configured to return stale responses to client
requests.
All LoST responses, including those indicating a LoST warning or All LoST responses, including those indicating a LoST warning or
error, are carried in 2xx responses, typically 200 (OK). Other 2xx error, are carried in 2xx responses, typically 200 (OK). Other 2xx
responses, in particular 203 (Non-authoritative information) may be responses, in particular 203 (Non-authoritative information), may be
returned by HTTP caches that disregard the caching instructions. 3xx, returned by HTTP caches that disregard the caching instructions. 3xx,
4xx and 5xx HTTP response codes indicates that the HTTP request 4xx, and 5xx HTTP response codes indicate that the HTTP request
itself failed or was redirected; these responses do not contain any itself failed or was redirected; these responses do not contain any
LoST XML elements. The 3xx responses are distinct from the redirects LoST XML elements. The 3xx responses are distinct from the redirects
which are described in Section 13.3; the 13.3 redirects occur after a that are described in Section 13.3; the redirect operation in
LoST server processes the request. Where an HTTP-layer redirect will Section 13.3 occur after a LoST server processes the request. Where
be general, a LoST server redirect as described in 13.3 might be an HTTP-layer redirect will be general, a LoST server redirect as
specific to a specific service or be the result of other processing described in Section 13.3 might be specific to a specific service or
by the LoST server. be the result of other processing by the LoST server.
The HTTP URL is derived from the LoST server name via U-NAPTR The HTTP URL is derived from the LoST server name via U-NAPTR
application, as discussed above. application, as discussed above.
15. Relax NG Schema 15. Relax NG Schema
This section provides the Relax NG schema used by LoST protocol in This section provides the Relax NG schema used by the LoST protocol
the compact form. The verbose form is included in Appendix A. in the compact form. The verbose form is included in Appendix A.
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost1" default namespace ns1 = "urn:ietf:params:xml:ns:lost1"
## ##
## Location-to-Service Translation Protocol (LoST) ## Location-to-Service Translation (LoST) Protocol
## ##
## A LoST XML instance has three request types, each with ## A LoST XML instance has three request types, each with
## a cooresponding response type: find service, list services, ## a corresponding response type: find service, list services,
## and get service boundary. ## and get service boundary.
## ##
start = start =
findService findService
| listServices | listServices
| listServicesByLocation | listServicesByLocation
| getServiceBoundary | getServiceBoundary
| findServiceResponse | findServiceResponse
| listServicesResponse | listServicesResponse
| listServicesByLocationResponse | listServicesByLocationResponse
skipping to change at page 51, line 20 skipping to change at page 44, line 36
tag: tag:
Application Service Tag: LoST Application Service Tag: LoST
Defining Publication: The specification contained within this Defining Publication: The specification contained within this
document. document.
This document registers the following U-NAPTR application protocol This document registers the following U-NAPTR application protocol
tags: tags:
o o Application Protocol Tag: http
Application Protocol Tag: http
Defining Publication: RFC 2616 [3] Defining Publication: RFC 2616 [3]
o o Application Protocol Tag: https
Application Protocol Tag: https
Defining Publication: RFC 2818 [4] Defining Publication: RFC 2818 [4]
17.2. Content-type registration for 'application/lost+xml' 17.2. Content-Type Registration for 'application/lost+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [7] and guidelines in RFC according to the procedures of RFC 4288 [7] and guidelines in RFC
3023 [5]. 3023 [5].
MIME media type name: application MIME media type name: application
MIME subtype name: lost+xml MIME subtype name: lost+xml
Mandatory parameters: none Mandatory parameters: none
skipping to change at page 52, line 14 skipping to change at page 45, line 23
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See RFC
3023 [5], Section 3.2. 3023 [5], Section 3.2.
Security considerations: This content type is designed to carry LoST Security considerations: This content type is designed to carry LoST
protocol payloads. protocol payloads.
Interoperability considerations: None Interoperability considerations: None
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFC 5222
replace XXXX with the RFC number of this specification.]
Applications which use this media type: Emergency and Location-based Applications that use this media type: Emergency and location-based
Systems systems
Additional information: Additional information:
Magic Number: None Magic Number: None
File Extension: .lostxml File Extension: .lostxml
Macintosh file type code: 'TEXT' Macintosh file type code: 'TEXT'
Personal and email address for further information: Hannes Personal and email address for further information:
Tschofenig, Hannes.Tschofenig@nsn.com Hannes Tschofenig, Hannes.Tschofenig@nsn.com
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: Author:
This specification is a work item of the IETF ECRIT working group, This specification is a work item of the IETF ECRIT working group,
with mailing list address <ecrit@ietf.org>. with mailing list address <ecrit@ietf.org>.
Change controller: Change controller:
The IESG <iesg@ietf.org> The IESG <iesg@ietf.org>
17.3. LoST Relax NG Schema Registration 17.3. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:schema:lost1 URI: urn:ietf:params:xml:schema:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@nsn.com). (Hannes.Tschofenig@nsn.com).
Relax NG Schema: The Relax NG schema to be registered is contained Relax NG Schema: The Relax NG schema to be registered is contained
skipping to change at page 53, line 47 skipping to change at page 46, line 43
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>LoST Namespace</title> <title>LoST Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for LoST</h1> <h1>Namespace for LoST</h1>
<h2>urn:ietf:params:xml:ns:lost1</h2> <h2>urn:ietf:params:xml:ns:lost1</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc5222.txt">
[NOTE TO IANA/RFC-EDITOR: RFC5222</a>.</p>
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body> </body>
</html> </html>
END END
17.5. LoST Location Profile Registry 17.5. LoST Location Profile Registry
This document seeks to create a registry of location profile names This document creates a registry of location profile names for the
for the LoST protocol. Profile names are XML tokens. This registry LoST protocol. Profile names are XML tokens. This registry will
will operate in accordance with RFC 2434 [2], Standards Action. operate in accordance with RFC 5226 [2], Standards Action.
geodetic-2d: geodetic-2d:
Defined in Section 12.2. Defined in Section 12.2.
civic: civic:
Defined in Section 12.3. Defined in Section 12.3.
18. Security Considerations 18. Security Considerations
There are several threats to the overall system of which service There are several threats to the overall system of which service
mapping forms a part. An attacker that can obtain service contact mapping forms a part. An attacker that can obtain service contact
URIs can use those URIs to attempt to disrupt those services. An URIs can use those URIs to attempt to disrupt those services. An
attacker that can prevent the lookup of contact URIs can impair the attacker that can prevent the lookup of contact URIs can impair the
reachability of such services. An attacker that can eavesdrop on the reachability of such services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an communication requesting this lookup can surmise the existence of an
skipping to change at page 55, line 16 skipping to change at page 47, line 28
There are several threats to the overall system of which service There are several threats to the overall system of which service
mapping forms a part. An attacker that can obtain service contact mapping forms a part. An attacker that can obtain service contact
URIs can use those URIs to attempt to disrupt those services. An URIs can use those URIs to attempt to disrupt those services. An
attacker that can prevent the lookup of contact URIs can impair the attacker that can prevent the lookup of contact URIs can impair the
reachability of such services. An attacker that can eavesdrop on the reachability of such services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an communication requesting this lookup can surmise the existence of an
emergency and possibly its nature, and may be able to use this to emergency and possibly its nature, and may be able to use this to
launch a physical attack on the caller. launch a physical attack on the caller.
To avoid an attacker modifying the query or its result, TLS MUST be To avoid an attacker modifying the query or its result, Transport
implemented and SHOULD be used. Use is RECOMMENDED both for clients' Layer Security (TLS) MUST be implemented and SHOULD be used. Use is
queries to servers and for queries among servers; this latter RECOMMENDED both for clients' queries to servers and for queries
recommendation is to help avoid LoST cache poisoning attacks by among servers; this latter recommendation is to help avoid LoST cache
replacing answers given to caching LoST servers. poisoning attacks by replacing answers given to caching LoST servers.
The use of server identity checks with TLS, as described in Section The use of server identity checks with TLS, as described in Section
3.1 of [4] is also RECOMMENDED. Omitting the server identity check 3.1 of [4], is also RECOMMENDED. Omitting the server identity check
allows an attacker to masquerade as a LoST server, so this approach allows an attacker to masquerade as a LoST server, so this approach
should be used only when getting any answer, even from a potentially should be used only when getting any answer, even from a potentially
malicious LoST server, is preferred over closing the connection (and malicious LoST server, is preferred over closing the connection (and
thus not getting any answer at all). The host name compared against thus not getting any answer at all). The host name compared against
the server certificate is the host name in the URI, not the DNS name the server certificate is the host name in the URI, not the DNS name
used as input to NAPTR resolution. used as input to NAPTR resolution.
Note that the security considerations in [22] recommend comparing the Note that the security considerations in [22] recommend comparing the
input of NAPTR resolution to the certificate, not the output (host input of NAPTR resolution to the certificate, not the output (host
name in the URI). This approach was not chosen because in emergency name in the URI). This approach was not chosen because in emergency
service use cases, it is likely that deployments will see a large service use cases, it is likely that deployments will see a large
number of inputs to the U-NAPTR algorithm resolving to a single number of inputs to the U-NAPTR algorithm resolving to a single
server, typically run by a local emergency services authority. In server, typically run by a local emergency services authority. In
this case, checking the input to the NAPTR resolution against the this case, checking the input to the NAPTR resolution against the
certificates provided by the LoST server would be impractical, as the certificates provided by the LoST server would be impractical, as the
list of organizations using it would be large, subject to rapid list of organizations using it would be large, subject to rapid
change, and unknown to the LoST server operator. change, and unknown to the LoST server operator.
The use of server identity does leave open the possibility of DNS The use of server identity does leave open the possibility of DNS-
based attacks, as the NAPTR records may be altered by an attacker. he based attacks, as the NAPTR records may be altered by an attacker.
attacks include, for example, interception of DNS packets between the The attacks include, for example, interception of DNS packets between
client and the recursive name server, DNS cache poisoning, and the client and the recursive name server, DNS cache poisoning, and
intentional modifications by the recursive name server; see [23] for intentional modifications by the recursive name server; see [23] for
more comprehensive discussion. more comprehensive discussion.
DNSSEC [20] can be used to protect against these threats. While DNS Security (DNSSEC) [20] can be used to protect against these
DNSSEC is incompletely deployed, users should be aware of the risk, threats. While DNSSEC is incompletely deployed, users should be
particularly when they are requesting NAPTR records in environments aware of the risk, particularly when they are requesting NAPTR
where the local recursive name server, or the network between the records in environments where the local recursive name server, or the
client and the local recursive name server, is not considered network between the client and the local recursive name server, is
trustworthy. not considered trustworthy.
LoST deployments which are unable to use DNSSEC and unwilling to LoST deployments that are unable to use DNSSEC and unwilling to trust
trust DNS resolution without DNSSEC, cannot use the NATPR-based DNS resolution without DNSSEC cannot use the NATPR-based discovery of
discovery of LoST servers as-is. When suitable configuration LoST servers as is. When suitable configuration mechanisms are
mechanisms are available, one possibility is to configure the LoST available, one possibility is to configure the LoST server URIs
server URIs (instead of the domain name to be used for NAPTR (instead of the domain name to be used for NAPTR resolution)
resolution) directly. Future specifications for applying LoST in directly. Future specifications for applying LoST in non-emergency
non-emergency services may also specify additional discovery services may also specify additional discovery mechanisms and name
mechanisms and name matching semantics. matching semantics.
Generally, LoST servers will not need to authenticate or authorize Generally, LoST servers will not need to authenticate or authorize
clients presenting mapping queries. If they do, an authentication of clients presenting mapping queries. If they do, an authentication of
the underlying transport mechanism, such as HTTP basic and digest the underlying transport mechanism, such as HTTP basic and digest
authentication MAY be used. Basic Authentication SHOULD only be used authentication, MAY be used. Basic authentication SHOULD only be
in combination with TLS. used in combination with TLS.
A more detailed description of threats and security requirements are A more detailed description of threats and security requirements is
provided in [17]. The threats and security requirements in non- provided in [17]. The threats and security requirements in non-
emergency service uses of LoST may be considerably different from emergency service uses of LoST may be considerably different from
those described here. For example, an attacker might seek monetary those described here. For example, an attacker might seek monetary
benefit by returning service mapping information which directed users benefit by returning service mapping information that directed users
to specific service providers. Before deploying LoST in new to specific service providers. Before deploying LoST in new
contexts, a thorough analysis of the threats and requirements contexts, a thorough analysis of the threats and requirements
specific to that context should be undertaken and decisions made on specific to that context should be undertaken and decisions made on
the appropriate mitigations. the appropriate mitigations.
19. Acknowledgments 19. Acknowledgments
We would like to the thank the following working group members for We would like to the thank the following working group members for
the detailed review of previous LoST document versions: the detailed review of previous LoST document versions:
skipping to change at page 57, line 13 skipping to change at page 49, line 4
the appropriate mitigations. the appropriate mitigations.
19. Acknowledgments 19. Acknowledgments
We would like to the thank the following working group members for We would like to the thank the following working group members for
the detailed review of previous LoST document versions: the detailed review of previous LoST document versions:
o Martin Thomson (Review July 2006) o Martin Thomson (Review July 2006)
o Jonathan Rosenberg (Review July 2006) o Jonathan Rosenberg (Review July 2006)
o Leslie Daigle (Review September 2006) o Leslie Daigle (Review September 2006)
o Shida Schubert (Review November 2006) o Shida Schubert (Review November 2006)
o Martin Thomson (Review December 2006) o Martin Thomson (Review December 2006)
o Barbara Stark (Review January 2007) o Barbara Stark (Review January 2007)
o Patrik Faeltstroem (Review January 2007 o Patrik Faltstrom (Review January 2007)
o Shida Schubert (Review January 2007 as a designated expert o Shida Schubert (Review January 2007 as a designated expert
reviewer) reviewer)
o Jonathan Rosenberg (Review February 2007) o Jonathan Rosenberg (Review February 2007)
o Tom Taylor (Review February 2007) o Tom Taylor (Review February 2007)
o Theresa Reese (Review February 2007) o Theresa Reese (Review February 2007)
o Shida Schubert (Review February 2007) o Shida Schubert (Review February 2007)
o James Winterbottom (Review July 2007) o James Winterbottom (Review July 2007)
o Karl Heinz Wolf (Review May and June 2007)
We would also like to thank the following working group members for We would also like to thank the following working group members for
their input to selected design aspects of the LoST protocol: their input to selected design aspects of the LoST protocol:
o Leslie Daigle and Martin Thomson (DNS-based LoST discovery o Leslie Daigle and Martin Thomson (DNS-based LoST discovery
procedure) procedure)
o John Schnizlein (authoritive LoST answers) o John Schnizlein (authoritive LoST answers)
o Rohan Mahy (display names) o Rohan Mahy (display names)
o James Polk (error handling) o James Polk (error handling)
o Ron Watro and Richard Barnes (expiry of cached data) o Ron Watro and Richard Barnes (expiry of cached data)
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James
Winterbottom (Indication of PSAP Confidence Level) Winterbottom (indication of PSAP confidence level)
o Martin Thomson (service boundary references) o Martin Thomson (service boundary references)
o Martin Thomson (service URN in LoST response message) o Martin Thomson (service URN in LoST response message)
o Clive D.W. Feather, Martin Thomson (Validation Functionality) o Clive D.W. Feather, Martin Thomson (validation functionality)
o Roger Marshall (PSAP preference in LoST response)
o Roger Marshall (PSAP Preference in LoST response)
o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, o James Winterbottom, Marc Linsner, Keith Drage, Tom Taylor, Martin
Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. Thomson, John Schnizlein, Shida Schubert, Clive D.W. Feather,
Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- Richard Stastny, John Hearty, Roger Marshall, Jean-Francois Mule,
Francois Mule, Pierre Desjardins (Location Profiles) Pierre Desjardins (location profiles)
o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, o Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson,
Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list
Keith (List Services functionality) services functionality)
o Thomson, Martin, Michael Hammer (Mapping of Services) o Martin Thomson, Michael Hammer (mapping of services)
o Shida Schubert, James Winterbottom, Keith Drage (default service o Shida Schubert, James Winterbottom, Keith Drage (default service
URN) URN)
o Otmar Lendl (LoST aggregation) o Otmar Lendl (LoST aggregation)
o Tom Taylor (Terminology) o Tom Taylor (terminology)
Klaus Darilion and Marc Linsner provided miscellaneous input to the Klaus Darilion and Marc Linsner provided miscellaneous input to the
design of the protocol. Finally, we would like to thank Brian Rosen design of the protocol. Finally, we would like to thank Brian Rosen,
who participated in almost every discussion thread. who participated in almost every discussion thread.
Early implementation efforts lead to good feedback by two open source Early implementation efforts led to good feedback by two open source
implementation groups. We would like to thank the implementers for implementation groups. We would like to thank the implementers for
their work and for helping us to improve the quality of the their work and for helping us to improve the quality of the
specification: specification:
o Wonsang Song o Wonsang Song
o Jong-Yul Kim o Jong-Yul Kim
o Anna Makarowska o Anna Makarowska
skipping to change at page 60, line 13 skipping to change at page 51, line 13
presence of overlapping coverage areas. presence of overlapping coverage areas.
20. References 20. References
20.1. Normative References 20.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
October 1998.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
skipping to change at page 60, line 36 skipping to change at page 51, line 35
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[7] Freed, N. and J. Klensin, "Media Type Specifications and [7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Daigle, L., "Domain-Based Application Service Location Using [8] Daigle, L., "Domain-Based Application Service Location Using
URIs and the Dynamic Delegation Discovery Service (DDDS)", URIs and the Dynamic Delegation Discovery Service (DDDS)",
RFC 4848, April 2007. RFC 4848, April 2007.
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", draft-ietf-ecrit-service-urn-07 and Other Well-Known Services", RFC 5031, January 2008.
(work in progress), August 2007.
[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in for Presence Information Data Format Location Object
progress), December 2007. (PIDF-LO)", RFC 5139, February 2008.
[11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
"Geographic information - Geography Markup Language (GML)", OGC "Geographic information - Geography Markup Language (GML)", OGC
Standard OpenGIS 03-105r1, April 2004. Standard OpenGIS 03-105r1, April 2004.
[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application [12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
Schema for use by the Internet Engineering Task Force (IETF)", Schema for use by the Internet Engineering Task Force (IETF)",
Candidate OpenGIS Implementation Specification , December 2006. Candidate OpenGIS Implementation Specification , December 2006.
20.2. Informative References 20.2. Informative References
[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work Recommendations", Work in Progress, February 2008.
in progress), February 2008.
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC 3921, Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
October 2004. October 2004.
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. December 2004.
[17] Taylor, T., "Security Threats and Requirements for Emergency [17] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
Call Marking and Mapping", draft-ietf-ecrit-security-threats-05 "Security Threats and Requirements for Emergency Call Marking
(work in progress), August 2007. and Mapping", RFC 5069, January 2008.
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies", RFC 5012,
draft-ietf-ecrit-requirements-13 (work in progress), January 2008.
March 2007.
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-03 (work in Framework", Work in Progress, September 2007.
progress), September 2007.
[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, "DNS Security Introduction and Requirements", RFC 4033,
March 2005. March 2005.
[21] Rosen, B. and J. Polk, "Best Current Practice for [21] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling", Work
draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008. in Progress, February 2008.
[22] Daigle, L. and A. Newton, "Domain-Based Application Service [22] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005. Service (DDDS)", RFC 3958, January 2005.
[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name [23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004. System (DNS)", RFC 3833, August 2004.
URIs
[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/ [24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/
RelaxNG> 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 Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost1" <grammar ns="urn:ietf:params:xml:ns:lost1"
xmlns="http://relaxng.org/ns/structure/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start> <start>
<a:documentation> <a:documentation>
Location-to-Service Translation Protocol (LoST) Location-to-Service Translation (LoST) Protocol
A LoST XML instance has three request types, each with A LoST XML instance has three request types, each with
a cooresponding response type: find service, list services, a corresponding response type: find service, list services,
and get service boundary. and get service boundary.
</a:documentation> </a:documentation>
<choice> <choice>
<ref name="findService" /> <ref name="findService" />
<ref name="listServices" /> <ref name="listServices" />
<ref name="listServicesByLocation" /> <ref name="listServicesByLocation" />
<ref name="getServiceBoundary" /> <ref name="getServiceBoundary" />
<ref name="findServiceResponse" /> <ref name="findServiceResponse" />
<ref name="listServicesResponse" /> <ref name="listServicesResponse" />
<ref name="listServicesByLocationResponse" /> <ref name="listServicesByLocationResponse" />
skipping to change at page 76, line 31 skipping to change at page 67, line 31
<define name="extensionPoint"> <define name="extensionPoint">
<a:documentation> <a:documentation>
A point where future extensions A point where future extensions
(elements from other namespaces) (elements from other namespaces)
can be added. can be added.
</a:documentation> </a:documentation>
<zeroOrMore> <zeroOrMore>
<ref name="notLost" /> <ref name="notLost" />
</zeroOrMore> </zeroOrMore>
</define> </define>
</div> </div>
</grammar> </grammar>
Figure 21 Figure 21
Appendix B. Examples On-line Appendix B. Examples Online
The XML examples and Relax NG schemas may be found on-line [24]. The XML examples and Relax NG schemas may be found online [24].
Authors' Addresses Authors' Addresses
Ted Hardie Ted Hardie
Qualcomm, Inc. Qualcomm, Inc.
Email: hardie@qualcomm.com EMail: hardie@qualcomm.com
Andrew Newton Andrew Newton
American Registry for Internet Numbers American Registry for Internet Numbers
3635 Concorde Parkway, Suite 200 3635 Concorde Parkway, Suite 200
Chantilly, VA 20151 Chantilly, VA 20151
US US
Phone: +1 703 227 9894 Phone: +1 703 227 9894
Email: andy@hxr.us EMail: andy@hxr.us
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 182 change blocks. 
414 lines changed or deleted 361 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/