draft-ietf-ecrit-lost-07.txt   draft-ietf-ecrit-lost-08.txt 
ECRIT T. Hardie ECRIT T. Hardie
Internet-Draft Qualcomm, Inc. Internet-Draft Qualcomm, Inc.
Intended status: Standards Track A. Newton Intended status: Standards Track A. Newton
Expires: August 10, 2008 American Registry for Internet Expires: September 29, 2008 American Registry for Internet
Numbers Numbers
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
February 7, 2008 March 28, 2008
LoST: A Location-to-Service Translation Protocol LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-07.txt draft-ietf-ecrit-lost-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2008. This Internet-Draft will expire on September 29, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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 PSAP for emergency services. location-appropriate Public Safety Answering Point (PSAP) for
emergency services.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Requirements Notation . . . . . . . . . . . . 6 2. Terminology and Requirements Notation . . . . . . . . . . . . 6
3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7
4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 9 4. LoST Servers and Their Resolution . . . . . . . . . . . . . . 9
5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10 5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10
5.1. The Mapping Data Source: 'source', 'sourceId' and 5.1. The Mapping Data Source: 'source', 'sourceId' and
'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10 'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 7 skipping to change at page 3, line 8
<findServiceResponse> . . . . . . . . . . . . . . . . . . 22 <findServiceResponse> . . . . . . . . . . . . . . . . . . 22
8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
8.4.2. Civic Address Validation: the 8.4.2. Civic Address Validation: the
<locationValidation> Element . . . . . . . . . . . . . 23 <locationValidation> Element . . . . . . . . . . . . . 23
9. Retrieving the Service Boundary via <getServiceBoundary> . . . 24 9. Retrieving the Service Boundary via <getServiceBoundary> . . . 24
10. List Services: <listServices> . . . . . . . . . . . . . . . . 27 10. List Services: <listServices> . . . . . . . . . . . . . . . . 27
11. List Services By Location: <listServicesByLocation> . . . . . 28 11. List Services By Location: <listServicesByLocation> . . . . . 28
12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30 12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31 12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31
12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34 12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34
12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 35 12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 36
13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37 13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37
13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39 13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39
13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40 13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40
14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42 14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42
15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43 15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43
16. Internationalization Considerations . . . . . . . . . . . . . 50 16. Internationalization Considerations . . . . . . . . . . . . . 50
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51 17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51
17.2. Content-type registration for 'application/lost+xml' . . . 51 17.2. Content-type registration for 'application/lost+xml' . . . 51
17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53
17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53
17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54
18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 18. Security Considerations . . . . . . . . . . . . . . . . . . . 55
19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
20.1. Normative References . . . . . . . . . . . . . . . . . . . 58 20.1. Normative References . . . . . . . . . . . . . . . . . . . 59
20.2. Informative References . . . . . . . . . . . . . . . . . . 59 20.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 61
Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 74 Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76
Intellectual Property and Copyright Statements . . . . . . . . . . 76 Intellectual Property and Copyright Statements . . . . . . . . . . 77
1. Introduction 1. Introduction
Protocols such as NAPTR records and the Service Location Protocol Protocols such as NAPTR records and the Service Location Protocol
(SLP) can be used to discover servers offering a particular service. (SLP) can be used to discover servers offering a particular service.
However, for an important class of services the appropriate specific However, for an important class of services the appropriate specific
service instance depends both on the identity of the service and the service instance depends both on the identity of the service and the
geographic location of the entity that needs to reach it. Emergency geographic location of the entity that needs to reach it. Emergency
telecommunications services are an important example; here, the telecommunications services are an important example; here, the
service instance is a Public Safety Answering Point (PSAP) that has service instance is a Public Safety Answering Point (PSAP) that has
jurisdiction over the location of the user making the call. The jurisdiction over the location of the user making the call. The
desired PSAP isn't necessarily the one that is topologically or even desired PSAP isn't necessarily the one that is topologically or even
line-of-sight closest to the caller; rather, it is the one that line-of-sight closest to the caller; rather, it is the one that
serves the caller's location based on jurisdictional boundaries. 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 PIDF-LO [6] to one and location information compatible with PIDF-LO [6] to one or more
or more service URIs. Service identifiers take the form of the service URIs. Service identifiers take the form of the service URNs
service URNs described in [9]. Location information here includes described in [9]. Location information here includes revised civic
revised civic location information [10] and a subset of the PIDL-LO location information [10] and a subset of the PIDL-LO profile [13]
profile [13] which consequently includes the Geo-Shapes [12] defined which consequently includes the Geo-Shapes [12] defined for GML [11].
for GML [11]. Example service URI schemes include sip [14], xmpp Example service URI schemes include sip [14], xmpp [15], and tel
[15], and tel [16]. While the initial focus is on providing mapping [16]. While the initial focus is on providing mapping functions for
functions for emergency services, it is likely that the protocol is emergency services, it is likely that the protocol is applicable to
applicable to other service URNs. For example, in the United States, other service URNs. For example, in the United States, the "2-1-1"
the "2-1-1" and "3-1-1" service numbers follow a similar location-to- and "3-1-1" service numbers follow a similar location-to-service
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
skipping to change at page 8, line 6 skipping to change at page 8, line 6
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;
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
[20], 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. beyond the boundaries of the service region. Service-specific Best
Curent Practice documents may also provide guidance on the contact
URI schemes most appropriate to the service. As a general set of
guidelines, URI schemes that do not provide mechanisms for actually
initiating a contact method should be avoided (examples include data,
info, cid, and tag) as transforming those references into contact
mechanisms requires a layer of indirection that makes the overall
mechanism more fragile. Provisionally registered URI schemes should
also be carefully considered before use, because they are subject to
change in core semantics.
4. LoST Servers and Their Resolution 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 [8] application unique
strings, in the form of a DNS name. An example is strings, in the form of a DNS name. An example is
'lostserver.example.com'. '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
skipping to change at page 14, line 15 skipping to change at page 14, line 15
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>elelment, including the first server to receive it. <path>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 5 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'
skipping to change at page 16, line 38 skipping to change at page 16, line 38
<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>
</p2:Point> </p2:Point>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 2: A <findService> geodetic query Figure 1: A <findService> geodetic query
Given the query above, a server would respond with a service, and Given the query above, a server would respond with a service, and
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 New York City Police Department, instructing the service to the New York City Police Department, instructing the
client that it may contact them via the URIs "sip:nypd@example.com" client that it may contact them via the URIs "sip:nypd@example.com"
and "xmpp:nypd@example.com". The server has also given the client a and "xmpp:nypd@example.com". The server has also given the client a
geodetic, two-dimensional boundary for this service. The mapping was geodetic, two-dimensional boundary for this service. The mapping was
last updated on November 1, 2006 and expires on January 1, 2007. If last updated on November 1, 2006 and expires on January 1, 2007. If
the client's location changes beyond the given service boundary or the client's location changes beyond the given service boundary or
skipping to change at page 17, line 41 skipping to change at page 17, line 41
<uri>xmpp:nypd@example.com</uri> <uri>xmpp: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="6020688f1ce1896d"/>
</findServiceResponse> </findServiceResponse>
Figure 3: A <findServiceResponse> geodetic answer Figure 2: A <findServiceResponse> geodetic answer
8.2.2. Civic Address Mapping Example 8.2.2. Civic Address Mapping Example
The example below shows how to map a service to a location much like The example below shows how to map a service to a location much like
the example in Section 8.2.1, but using civic address location the example in Section 8.2.1, but using civic address location
information. In this example, the client requests the service information. In this example, the client requests the service
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).
skipping to change at page 18, line 22 skipping to change at page 18, line 22
<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>
Figure 4: A <findService> civic address query Figure 3: A <findService> civic address query
Given the query above, a server would respond with a service, and Given the query above, a server would respond with a service, and
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
skipping to change at page 19, line 37 skipping to change at page 19, line 37
<uri>xmpp:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber> <serviceNumber>110</serviceNumber>
</mapping> </mapping>
<path> <path>
<via source="esgw.ueber-110.de.example"/> <via source="esgw.ueber-110.de.example"/>
<via source="polizei.muenchen.de.example"/> <via source="polizei.muenchen.de.example"/>
</path> </path>
<locationUsed id="627b8bf819d0bad4d"/> <locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse> </findServiceResponse>
Figure 5: 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
skipping to change at page 20, line 47 skipping to change at page 20, line 47
<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
the <findService> request, but the server makes the final decision as the <findService> request, but the server makes the final decision as
to whether to return a reference or a value. to whether to return a reference or a value.
8.3.5. Requesting Civic Location Validation 8.3.5. Requesting Civic Location Validation
Civic address validation is requested by setting the optional Civic address validation is requested by setting the optional
attribute 'validateLocation' to true. If the attribute is omitted, attribute 'validateLocation' to true. If the attribute is omitted,
it is assumed to be false. The response is described in it is assumed to be false. The response is described in
Section 8.4.2. The example in Figure 6 demonstrates address Section 8.4.2. The example in Figure 5 demonstrates address
validation. If the server chooses a geodetic location among the validation. If the server chooses a geodetic location among the
locations provided in a request, the attribute is ignored. locations provided in a request, the attribute is ignored.
<?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"
recursive="true" recursive="true"
validateLocation="true" validateLocation="true"
serviceBoundary="value"> serviceBoundary="value">
<location id="627b8bf819d0bad4d" profile="civic"> <location id="627b8bf819d0bad4d" profile="civic">
skipping to change at page 21, line 25 skipping to change at page 21, line 25
<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>
Figure 6: A <findService> query with address validation request Figure 5: A <findService> query with address validation request
<?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="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>
skipping to change at page 22, line 40 skipping to change at page 22, line 40
<invalid>PC</invalid> <invalid>PC</invalid>
<unchecked>HNO</unchecked> <unchecked>HNO</unchecked>
</locationValidation> </locationValidation>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="627b8bf819d0bad4d"/> <locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse> </findServiceResponse>
Figure 7: A <findServiceResponse> message with address validation Figure 6: A <findServiceResponse> message with address validation
information information
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.
skipping to change at page 23, line 31 skipping to change at page 23, line 31
civic address elements found in the <valid> list. Civic location civic address elements found in the <valid> list. Civic location
tokens that are neither listed in the <valid>, the <invalid> and the tokens that are neither listed in the <valid>, the <invalid> and the
<unchecked> element belong to the class of unchecked tokens. <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 6 and in Figure 7 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>
element as not valid for this location. The 'HNO' token belongs to element as not valid for this location. The 'HNO' token belongs to
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 8 and the boundary by value. This is shown in the example in Figure 7 and
Figure 9. 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 <getServiceBoundaryResponse>, illustrated in the example in Figure 9.
Figure 10. The client issues the request to the server identified in The client issues the request to the server identified in the
the 'server' attribute of the <serviceBoundaryReference> element. 'server' attribute of the <serviceBoundaryReference> element. These
These requests are always directed to the authoritative server and do requests are always directed to the authoritative server and do not
not recurse. 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>
</p2:Point> </p2:Point>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 8: <findService> request and response with service boundary Figure 7: <findService> request and response with service boundary
reference reference
<?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/gml"> xmlns:p2="http://www.opengis.net/gml">
<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="authoritative.example" source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"> sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en"> <displayName xml:lang="en">
skipping to change at page 25, line 30 skipping to change at page 25, line 30
<uri>xmpp:nypd@example.com</uri> <uri>xmpp: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="6020688f1ce1896d"/>
</findServiceResponse> </findServiceResponse>
Figure 9: <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 10: Requesting a service boundary with <getServiceBoundary> Figure 9: Requesting a service boundary with <getServiceBoundary>
The <getServiceBoundary> request may also be used to retrieve service The <getServiceBoundary> request may also be used to retrieve service
boundaries that are expressed as civic addresses, as illustrated in boundaries that are expressed as civic addresses, as illustrated in
Figure 11. 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="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country> <country>US</country>
<A1>New York</A1> <A1>New York</A1>
<A3>New York</A3> <A3>New York</A3>
</civicAddress> </civicAddress>
</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 11: Civic Address Service Boundary Response Figure 10: Civic Address 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 and no path indication. 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 12. 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>
Figure 12: Example of <ListServices> query Figure 11: Example of <ListServices> query
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServicesResponse <listServicesResponse
xmlns="urn:ietf:params:xml:ns:lost1"> xmlns="urn:ietf:params:xml:ns:lost1">
<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
skipping to change at page 27, line 48 skipping to change at page 27, line 48
urn:service:sos.poison urn:service:sos.poison
urn:service:sos.police urn:service:sos.police
urn:service:sos.suicide 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>
</listServicesResponse> </listServicesResponse>
Figure 13: Example of <ListServiceResponse> Figure 12: Example of <ListServiceResponse>
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
skipping to change at page 28, line 33 skipping to change at page 28, line 33
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>
element, consisting of a whitespace-separated list of service URNs. element, consisting of a whitespace-separated list of service URNs.
The query and response are illustrated in Figure 14 and in Figure 15, The query and response are illustrated in Figure 13 and in Figure 14,
respectively. respectively.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation <listServicesByLocation
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">
<location id="3e19dfb3b9828c3" profile="geodetic-2d"> <location id="3e19dfb3b9828c3" profile="geodetic-2d">
<p2:Point srsName="urn:ogc:def:crs:EPSG::4326"> <p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>-34.407 150.883</p2:pos> <p2:pos>-34.407 150.883</p2:pos>
</p2:Point> </p2:Point>
</location> </location>
<service>urn:service:sos</service> <service>urn:service:sos</service>
</listServicesByLocation> </listServicesByLocation>
Figure 14: Example of <ListServicesbyLocation> query Figure 13: Example of <ListServicesbyLocation> query
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse <listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1"> xmlns="urn:ietf:params:xml:ns:lost1">
<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
skipping to change at page 29, line 26 skipping to change at page 29, line 26
urn:service:sos.police urn:service:sos.police
urn:service:sos.suicide 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 15: Example of <ListServices> response Figure 14: Example of <ListServices> 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 33, line 43 skipping to change at page 33, line 43
</gs:Prism> </gs:Prism>
</location> </location>
<location id="DEF 345" profile="geodetic-2d"> <location id="DEF 345" profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>42.656844 -73.348157</gml:pos> <gml:pos>42.656844 -73.348157</gml:pos>
</gml:Point> </gml:Point>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 16: Example of a <findServices> query with baseline profile Figure 15: Example of a <findServices> query with baseline profile
interoperability interoperability
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse <findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/"> xmlns:p2="http://www.opengis.net/">
<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="authoritative.example" source="authoritative.example"
sourceId="cf19bbb038fb4ade95852795f045387d"> sourceId="cf19bbb038fb4ade95852795f045387d">
skipping to change at page 34, line 40 skipping to change at page 34, line 40
<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="6020688f1ce1896d"/>
</findServiceResponse> </findServiceResponse>
Figure 17: 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 "geodetic-2d".
Clients and servers use this profile by placing the following Clients and servers use this profile by placing the following
location shapes into the <serviceBoundary> or into the <location> location shapes into the <serviceBoundary> or into the <location>
element (unless indicated otherwise): element (unless indicated otherwise):
Point: Point:
skipping to change at page 35, line 34 skipping to change at page 35, line 34
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 clients place a <Polygon>, <Circle>, <Ellipse> or <ArcBand> When a client uses a <Polygon>, <Circle>, <Ellipse> or <ArcBand>
element within the <location> element then it indicates that the element within the <location> element, it is indicating that it will
query is about any point contained in the given area; it is left to be satisfied by query results appropriate to any portion of the
the server to select an appropriate matching algorithm, such as using shape. It is left to the server to select an appropriate matching
computing the centroid. A server MAY return multiple <mapping> algorithm. A server MAY return multiple <mapping> elements if the
elements if the polygon extends across multiple service areas. shape extends across multiple service areas. Servers are not
required to return all possible <mapping> elements to avoid denial of
service attacks in which clients present queries that span a very
large number service boundaries (e.g. presenting a shape covering all
of the United States).
In the case where the server does not return multiple <mapping>
elements, but the shape extends across a service boundary, it is
possible that the matching algorithm selected by the LoST server will
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
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
within the shape given. In emergency service use cases, that may
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
expected part of the overall emergency response system. In non-
emergency service use cases, the service deployment model should take
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
mapping determine which contact URIs are returned when shapes are
used which overlap multiple service areas.
As a general guideline, any deployed matching algorithm should ensure
that the algorithm used does not needlessly return NULL results if
there are valid results for any portion of the shape.
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
skipping to change at page 39, line 11 skipping to change at page 39, line 11
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 18: Example of an error resonse Figure 17: Example of an error resonse
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.
skipping to change at page 40, line 44 skipping to change at page 40, line 44
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 19: Example of an warning resonse Figure 18: Example of an warning resonse
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. querier. The "expires" value in the response returned by the server
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
tuple of location and service SHOULD NOT be directed to the server
which 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 20: 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 mechanisms 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; other mechanisms are left to future HTTP and LoST over HTTP-over-TLS. Client and server developers are
documents. The available transport mechanisms are determined through reminded that full support of RFC 2616 HTTP facilities is expected.
the use of the LoST U-NAPTR application. In protocols that support If LoST clients or servers re-implement HTTP, rather than using
content type indication, LoST uses the media type application/ available servers or client code as a base, careful attention must be
lost+xml. paid to full interoperability. Other transport mechanisms are left
to future documents. The available transport mechanisms are
determined through the use of the LoST U-NAPTR application. In
protocols that support content type indication, LoST uses the media
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 HTTP-level caching even by caches that have
been configured to return stale responses to client requests." 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 indicates 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 which are described in Section 13.3; the 13.3 redirects occur after a
LoST server processes the request. Where an HTTP-layer redirect will LoST server processes the request. Where an HTTP-layer redirect will
skipping to change at page 49, line 36 skipping to change at page 49, line 36
| text)* | text)*
## ##
## A point where future extensions ## A point where future extensions
## (elements from other namespaces) ## (elements from other namespaces)
## can be added. ## can be added.
## ##
extensionPoint = notLost* extensionPoint = notLost*
} }
Figure 21: RelaxNG schema Figure 20: RelaxNG schema
16. Internationalization Considerations 16. Internationalization Considerations
The LoST protocol is mostly meant for machine-to-machine The LoST protocol is mostly meant for machine-to-machine
communications; as such, most of its elements are tokens not meant communications; as such, most of its elements are tokens not meant
for direct human consumption. If these tokens are presented to the for direct human consumption. If these tokens are presented to the
end user, some localization may need to occur. The content of the end user, some localization may need to occur. The content of the
<displayName> element and the 'message' attributes may be displayed <displayName> element and the 'message' attributes may be displayed
to the end user, and they are thus complex types designed for this to the end user, and they are thus complex types designed for this
purpose. purpose.
skipping to change at page 55, line 16 skipping to change at page 55, line 16
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 that an attacker can modify the query or its result, TLS To avoid an attacker modifying the query or its result, TLS MUST be
MUST be implemented and SHOULD be used. Use is RECOMMENDED both for implemented and SHOULD be used. Use is RECOMMENDED both for clients'
clients' queries to servers and for queries among servers; this queries to servers and for queries among servers; this latter
latter recommendation is to help avoid cache poisoning attacks by recommendation is to help avoid LoST cache poisoning attacks by
replacing answers given to caching servers. The use of server replacing answers given to caching LoST servers. The use of server
identity checks is also RECOMMENDED, as described in [4] identity checks is also RECOMMENDED, as described in [4] .
Generally, authentication and authorization is not required for In emergency service use cases, it is likely that deployments will
mapping queries. If it is, authentication mechanism of the see a large number of inputs to the U-NAPTR algorithm resolving to a
underlying transport mechanism, such as HTTP basic and digest single server. This is because local organizations will likely be
authentication, MAY be used. (Basic authentication SHOULD only be permitted or even encouraged to use LoST servers provided by the
used in combination with TLS.) local emergency services authority. This makes the use of
alternatives to server identity which would check the input to the
U-NAPTR algorithm against the certificates provided by the LoST
server impractical, as the list of organizations using it would be
large, subject to rapid change, and unknown to the LoST server
operator. The use of server identity does leave open the possibility
of DNS cache poisoning attacks, as the NAPTR records may be altered
by an attacker. U-NAPTR recommends DNSSEC [20] as protection. While
DNSSEC is incompletely deployed, users should be aware of the risk,
particularly when they are requesting NAPTR records for domains or
from servers with which they have no previous trust relationship.
Generally, LoST servers will not need to authenticate or authorize
clients presenting mapping queries. If they do, an authentication of
the underlying transport mechanism, such as HTTP basic and digest
authentication MAY be used. Basic Authentication SHOULD only be used
in combination with TLS.
A more detailed description of threats and security requirements are A more detailed description of threats and security requirements are
provided in [17]. provided in [17]. The threats and security requirements in non-
emergency service uses of LoST may be considerably different from
those described here. For example, an attacker might seek monetary
benefit by returning service mapping information which directed users
to specific service providers. Before deploying LoST in new
contexts, a thorough analysis of the threats and requirements
specific to that context should be undertaken and decisions made on
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)
skipping to change at page 59, line 9 skipping to change at page 60, line 9
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-10 (work Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work
in progress), October 2007. 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,
skipping to change at page 59, line 36 skipping to change at page 60, line 36
[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",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
March 2007. 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", draft-ietf-ecrit-mapping-arch-03 (work in
progress), September 2007. progress), September 2007.
[20] Rosen, B. and J. Polk, "Best Current Practice for [20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[21] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-03 (work in progress), November 2007. draft-ietf-ecrit-phonebcp-04 (work in progress), February 2008.
URIs URIs
[21] <http://www.tschofenig.com/svn/draft-ietf-ecrit-lost/RelaxNG> [22] <http://www.tschofenig.com/svn/draft-ietf-ecrit-lost/RelaxNG>
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>
skipping to change at page 74, line 36 skipping to change at page 75, line 36
</a:documentation> </a:documentation>
<zeroOrMore> <zeroOrMore>
<ref name="notLost" /> <ref name="notLost" />
</zeroOrMore> </zeroOrMore>
</define> </define>
</div> </div>
</grammar> </grammar>
Figure 25 Figure 21
Appendix B. Examples On-line Appendix B. Examples On-line
The XML examples and Relax NG schemas may be found on-line [21]. The XML examples and Relax NG schemas may be found on-line [22].
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
skipping to change at page 77, line 44 skipping to change at line 3014
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 53 change blocks. 
98 lines changed or deleted 164 lines changed or added

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