draft-ietf-ecrit-lost-05.txt | draft-ietf-ecrit-lost-06.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: September 5, 2007 SunRocket | Expires: February 11, 2008 TranTech, Inc. | |||
H. Schulzrinne | H. Schulzrinne | |||
Columbia U. | Columbia University | |||
H. Tschofenig | H. Tschofenig | |||
Siemens Networks GmbH & Co KG | Nokia Siemens Networks | |||
March 4, 2007 | August 10, 2007 | |||
LoST: A Location-to-Service Translation Protocol | LoST: A Location-to-Service Translation Protocol | |||
draft-ietf-ecrit-lost-05.txt | draft-ietf-ecrit-lost-06.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 39 | skipping to change at page 1, line 39 | |||
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 September 5, 2007. | This Internet-Draft will expire on February 11, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
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 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 Data Source: 'source', 'sourceId' and | 5.1. The Mapping Data Source: 'source', 'sourceId' and | |||
'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10 | 'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10 | |||
5.2. Validity: The 'expires' Attribute . . . . . . . . . . . . 10 | 5.2. Mapping Validity: The 'expires' Attribute . . . . . . . . 10 | |||
5.3. Describing the Service with the <displayName> Element . . 11 | 5.3. Describing the Service with the <displayName> Element . . 11 | |||
5.4. The Mapped Service: the <service> Element . . . . . . . . 11 | 5.4. The Mapped Service: the <service> Element . . . . . . . . 11 | |||
5.5. Defining the Service Region with the <serviceBoundary> | 5.5. Defining the Service Region with the <serviceBoundary> | |||
Element . . . . . . . . . . . . . . . . . . . . . . . . . 11 | Element . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.6. Service Boundaries by Reference: the | 5.6. Service Boundaries by Reference: the | |||
<serviceBoundaryReference> Element . . . . . . . . . . . . 12 | <serviceBoundaryReference> Element . . . . . . . . . . . . 12 | |||
5.7. The Service Number Element . . . . . . . . . . . . . . . . 13 | 5.7. The Service Number: the <serviceNumber> Element . . . . . 13 | |||
5.8. Service URLs: the <uri> Element . . . . . . . . . . . . . 13 | 5.8. Service URLs: the <uri> Element . . . . . . . . . . . . . 13 | |||
6. Path of a Request: <path> Element . . . . . . . . . . . . . . 14 | 6. Path of a Request: the <path> Element . . . . . . . . . . . . 14 | |||
7. Mapping a Location and Service to URLs: <findService> . . . . 15 | 7. Identifying the Location Element Used for Mapping: | |||
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 | <locationUsed> . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 8. Mapping a Location and Service to URLs: <findService> . . . . 16 | |||
7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 15 | 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 16 | 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
7.3. Components of the <findService> Request . . . . . . . . . 18 | 8.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 16 | |||
7.3.1. The <location> Element . . . . . . . . . . . . . . . . 18 | 8.2.2. Civic Address Mapping Example . . . . . . . . . . . . 17 | |||
7.3.2. Identifying the Service: The <service> Element . . . 19 | 8.3. Components of the <findService> Request . . . . . . . . . 19 | |||
7.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 19 | 8.3.1. The <location> Element . . . . . . . . . . . . . . . . 19 | |||
7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 19 | 8.3.2. Identifying the Service: The <service> Element . . . 20 | |||
7.3.5. Requesting Civic Location Validation . . . . . . . . . 19 | 8.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 20 | |||
7.4. Components of the Mapping Response | 8.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 20 | |||
<findServiceResponse> . . . . . . . . . . . . . . . . . . 21 | 8.3.5. Requesting Civic Location Validation . . . . . . . . . 20 | |||
7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21 | 8.4. Components of the Mapping Response | |||
7.4.2. Civic Address Validation: the | <findServiceResponse> . . . . . . . . . . . . . . . . . . 22 | |||
<locationValidation> Element . . . . . . . . . . . . . 22 | 8.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
8. Retrieving the Service Boundary via <getServiceBoundary> . . . 23 | 8.4.2. Civic Address Validation: the | |||
9. List Services: <listServices> . . . . . . . . . . . . . . . . 26 | <locationValidation> Element . . . . . . . . . . . . . 23 | |||
10. List Services By Location: <listServicesByLocation> . . . . . 27 | 9. Retrieving the Service Boundary via <getServiceBoundary> . . . 24 | |||
11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 29 | 10. List Services: <listServices> . . . . . . . . . . . . . . . . 27 | |||
11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 30 | 11. List Services By Location: <listServicesByLocation> . . . . . 28 | |||
11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 33 | 12. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 30 | |||
11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 34 | 12.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 31 | |||
12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 35 | 12.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 34 | |||
12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 12.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 35 | |||
12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 36 | 13. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 37 | |||
12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 37 | 13.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 38 | 13.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 39 | 13.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
15. Internationalization Considerations . . . . . . . . . . . . . 46 | 14. LoST Transport: HTTP . . . . . . . . . . . . . . . . . . . . . 42 | |||
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | 15. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 47 | 16. Internationalization Considerations . . . . . . . . . . . . . 50 | |||
16.2. Content-type registration for 'application/lost+xml' . . . 47 | 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 | |||
16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 49 | 17.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 51 | |||
16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 49 | 17.2. Content-type registration for 'application/lost+xml' . . . 51 | |||
16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 50 | 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 | |||
17. Security Considerations . . . . . . . . . . . . . . . . . . . 51 | 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 | |||
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 | 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 | |||
19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 54 | 18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 | |||
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 | 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 | |||
20.1. Normative References . . . . . . . . . . . . . . . . . . . 55 | 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 | |||
20.2. Informative References . . . . . . . . . . . . . . . . . . 56 | 20.1. Normative References . . . . . . . . . . . . . . . . . . . 58 | |||
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 57 | 20.2. Informative References . . . . . . . . . . . . . . . . . . 59 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 | Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 71 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 75 | ||||
1. Introduction | 1. Introduction | |||
Numerous techniques have been specified for the discovery of servers | Protocols such as NAPTR records and the Service Location Protocol | |||
for a particular service, including NAPTR records, SVRLOC and similar | (SLP) can be used to discover servers offering a particular service. | |||
protocols. However, there are an important class of services where | However, for an important class of services the appropriate specific | |||
the specific service instance that is to be connected to depends on | service instance depends both on the identity of the service and the | |||
the identity of the service and the location of the entity that needs | geographic location of the entity that needs to reach it. Emergency | |||
to reach it. An example of this is emergency telecommunications | telecommunications services are an important example; here, the | |||
services, where the service instance is a Public Safety Answering | service instance is a Public Safety Answering Point (PSAP) that has | |||
Point (PSAP) that has jurisdiction over the location of the user | jurisdiction over the location of the user making the call. The | |||
making the call. Here, the desired PSAP isn't necessarily the one | desired PSAP isn't necessarily the one that is topologically or even | |||
that is topologically or even line-of-sight closest to the caller; | line-of-sight closest to the caller; rather, it is the one that | |||
rather, it is the one that serves the callers location based on | serves the callers location based on jurisdictional boundaries. | |||
geopolitical boundaries. For this reason, the selected service | ||||
instance is a function of location and the desired service. | ||||
This document describes a protocol for mapping a service identifier | This document describes a protocol for mapping a service identifier | |||
[9] and location information compatible with PIDF-LO [6], namely | (service URNs) [9] and location information compatible with PIDF-LO | |||
revised civic location information [10] and GML [12]) to one or more | [6], namely revised civic location information [10] and a subset of | |||
service URL. Example service URL schemes include sip [14], xmpp | the PIDF-LO profile [13] and consequently with the Geo-Shapes [12] | |||
[15], and tel [16]. While the initial focus is on providing mapping | defined for GML [11]) to one or more service URLs. Example service | |||
functions for emergency services, it is likely that the protocol is | URL schemes include sip [14], xmpp [15], and tel [16]. While the | |||
applicable to any service URN. For example, in the United States, | initial focus is on providing mapping functions for emergency | |||
the "2-1-1" and "3-1-1" service numbers follow a similar location-to- | services, it is likely that the protocol is applicable to other | |||
service behavior as emergency services. | service URNs. For example, in the United States, the "2-1-1" and | |||
"3-1-1" service numbers follow a similar location-to-service behavior | ||||
as emergency services. | ||||
This document names this protocol "LoST", for Location-to-Service | 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 (see Section 3.5 of [18] | invalid, thus providing address validation, as described in Section | |||
for a description of validation). LoST indicates errors in the | 3.5 of [18]. LoST indicates errors in the location data to | |||
location data to facilitate debugging and proper user feedback, but | facilitate debugging and proper user feedback, but also provides | |||
also provides best-effort answers. | best-effort answers. | |||
LoST queries can be resolved recursively or iteratively. To minimize | LoST queries can be resolved recursively or iteratively. To minimize | |||
round trips and to provide robustness against network failures, LoST | round trips and to provide robustness against network failures, LoST | |||
supports caching of individual mappings and indicates the region for | supports caching of individual mappings and indicates the region for | |||
which the same answer would be returned ("service region"). | which the same answer would be returned ("service region"). | |||
As defined in this document, LoST messages are carried in HTTP and | As defined in this document, LoST messages are carried in HTTP and | |||
HTTPS protocol exchanges, facilitating use of TLS for protecting the | HTTPS protocol exchanges, facilitating use of TLS for protecting the | |||
integrity and confidentiality of requests and responses. | integrity and confidentiality of requests and responses. | |||
skipping to change at page 5, line 18 | skipping to change at page 5, line 18 | |||
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 (URI) 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 7, the protocol also | to the mapping function described in Section 8, the protocol also | |||
allows to retrieve the service boundary (see Section 8) and to list | allows to retrieve the service boundary (see Section 9) and to list | |||
the services available for a particular location (see Section 10) or | the services available for a particular location (see Section 11) or | |||
supported by a particular server (see Section 9). | 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: Mapping is a process that takes a location and a service | |||
identifier as inputs and returns one or more URIs. Those URIs can | ||||
Mapping is a process that takes a location and a service | either point to a host providing that service or to a host that in | |||
identifier as inputs and returns one or more URIs that point to a | turn routes the request to the final destination. This definition | |||
host providing that service or acting as an intermediary to | ||||
establish communication with the serving entity. 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 | |||
of the potential for LoST to be used for non-emergency services. | LoST can be used for non-emergency services. | |||
LoST Client and Server: | LoST client: A host acts as a LoST client if it sends LoST query | |||
messages and receives LoST response messages. | ||||
"LoST client" is the role played by an entity that sends LoST | LoST server: A host acts as a LoST server if it receives LoST query | |||
query messages and receives LoST response messages. "LoST server" | messages and sends LoST response messages. In recursive | |||
is the role played by an entity that 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 play both roles. This document also uses the term | ||||
"authoritative server" to designate an entity that acts in the | ||||
LoST server role only and successfully resolves the input location | ||||
and service identifier to a URI or set of URIs. | ||||
Service Boundary: | Authoritative LoST server: An authoritative server acts only as a | |||
server and successfully resolves the input location and service | ||||
identifier to a URI or set of URIs. | ||||
A service boundary is the boundary or set of boundaries of a | Service boundary: A service boundary circumscribes the region within | |||
geographic region, respectively set of geographic regions, within | which all locations map to the same service URI or set of URIs for | |||
which all locations will map to the same URI or set of URIs for a | a given service. A service boundary may consist of several non- | |||
given service. | contiguous geometric shapes. | |||
Validation: | Validation: | |||
The term "validation" as used in this document is a concrete | The term "validation" describes the behavior defined as "location | |||
realization of the term "location validation" as defined in | validation" in Section 3.5 of [18]. | |||
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 type of queries and | |||
responses: | responses: | |||
<findService> and <findServiceResponse> | <findService> and <findServiceResponse> | |||
This message pattern allows to perform retrieve contact URIs based | A LoST client retrieves contact URIs based on location information | |||
on location information together with a service identifier. The | and a service identifier with this request and response. The same | |||
same query type may also ask for location validation and for | query type may also ask for location validation and for service | |||
service numbers, either integrated into mapping request or | numbers, either combined with a mapping request or separately. | |||
separately. The details can be found in Section 7 and | The details can be found in Section 8 and Section 8.4. | |||
Section 7.4. | ||||
<getServiceBoundary> and <getServiceBoundaryResponse> | <getServiceBoundary> and <getServiceBoundaryResponse> | |||
This message pattern allows query for a service boundary. The | A LoST client obtains a service boundary with this request and | |||
details can be found in Section 8. | response, as described in Section 9. | |||
<listServices> and <listServicesResponse> | <listServices> and <listServicesResponse> | |||
This message pattern enables a LoST client to ask a LoST server | With this request and response, a LoST client can find out which | |||
for the services it supports. The details can be found in | services a LoST server supports, as described in Section 10. | |||
Section 9. | ||||
<listServicesByLocation> and <listServicesByLocationResponse> | <listServicesByLocation> and <listServicesByLocationResponse> | |||
This message pattern provides the LoST client with the services | A LoST client can determine with this request and response which | |||
that are available for a specific location region. The details | services are available for a specific location region. Section 11 | |||
can be found in Section 10. | 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. An incoming message at a SIP proxy in a location-based routing | 3. when a SIP message arrives at a SIP proxy performing location- | |||
scenario that requires a routing decision to be made. | 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 | [20], 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. | |||
4. LoST servers and Their Resolution | 4. LoST Servers and Their Resolution | |||
LoST servers are identified by U-NAPTR/DDDS [11] application unique | ||||
strings, in the form of a DNS name. | ||||
An example is 'lostserver.example.com' | LoST servers are identified by U-NAPTR/DDDS [8] application unique | |||
strings, in the form of a DNS name. An example is | ||||
'lostserver.example.com'. | ||||
Clients need to use the U-NAPTR [11] 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 | |||
preferred. | preferred. | |||
skipping to change at page 10, line 11 | skipping to change at page 10, line 11 | |||
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. | |||
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 Data Source: 'source', 'sourceId' and 'lastUpdated' Attributes | 5.1. The Mapping Data Source: 'source', 'sourceId' and 'lastUpdated' | |||
Attributes | ||||
The 'source', the 'sourceId' and the 'lastUpdated' attributes | The 'source', the 'sourceId' and the 'lastUpdated' attributes | |||
uniquely identify a particular mapping record. They are created by | uniquely identify a particular mapping record. They are created by | |||
the authoritative source for a mapping and never modified when a | the 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 | |||
datum 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. See | identifying the authoritative generator of the mapping (Section 4). | |||
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 canonical UTC | |||
representation with the letter 'Z' as the timezone indicator. | representation with the letter 'Z' as the timezone indicator. | |||
5.2. 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. See | |||
Section 3 regarding how this value is to be utilized with a cache. | Section 3 regarding how this value is to be utilized with a cache. | |||
The 'expires' attribute is REQUIRED to be included in the <mapping> | The 'expires' attribute is REQUIRED to be included in the <mapping> | |||
element. | 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 | |||
skipping to change at page 11, line 10 | skipping to change at page 11, line 10 | |||
'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 | |||
that have such stale information SHOULD re-attempt the query each | that have such stale information SHOULD re-attempt the query each | |||
time a client requests a mapping. Since the expired mapping will be | time a client requests a mapping. Since the expired mapping will be | |||
returned to the client as a non-error/non-warning response it is the | returned to the client as a non-error/non-warning response it is the | |||
responsibility of the client to check the 'expires' attribute | responsibility of the client to check the 'expires' attribute | |||
associated with mapping data returned in a LoST response to detemine | associated with mapping data returned in a LoST response to determine | |||
whether the mapping is fresh. | whether the mapping is fresh. | |||
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 <service> element identifies the service for which this mapping | The mandatory <service> element identifies the service for which this | |||
applies. Two cases need to be distinguished when the LoST server | mapping applies. Two cases need to be distinguished when the LoST | |||
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 puts 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 can either return an | |||
<serviceNotImplemented> (Section 12.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. | |||
The <service> element is optional but may also be required if the | ||||
mapping is to be digitally signed. | ||||
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 (see Section 5.6). If a client moves outside the service | reference (see Section 5.6). If a client moves outside the service | |||
area and wishes to obtain current service data, it sends a new query | area and wishes to obtain current service data, it sends a new query | |||
with its current location. The service region is described by value | with its current location. The service region is described by value | |||
in one or more <serviceBoundary> elements, each formatted according | in one or more <serviceBoundary> elements, each formatted according | |||
to a different location profile, identified by the 'profile' atribute | to a specific location profile, identified by the 'profile' attribute | |||
(see Section 11). If included in a response, the <serviceBoundary> | (see Section 12). serviceBoundary elements formatted according to | |||
element MUST contain at least one service boundary that uses the same | different location profiles are alternative representations of the | |||
profile as the request. The client only processes the first element | same area, not additive to one another; this allows a client | |||
that it can understand according to its list of supported location | understanding only one of the profile types to be sure it has a | |||
profiles. Thus, elements with geospatial coordinates are alternative | complete view of the serviceBoundary. Within a serviceBoundary | |||
descriptions of the same service region, not additive geometries. | element there may, however, be multiple locations which _are_ | |||
additive; this is necessary because some serviceBoundary areas could | ||||
not be easily expressed with a single shape or civic location. If | ||||
included in a response, the <serviceBoundary> element MUST contain at | ||||
least one service boundary that uses the same profile as the request. | ||||
A service boundary is requested by the client (using the | 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". | |||
A response MAY contain more than one <serviceBoundary> element with | ||||
profile 'civic'. Each <serviceBoundary> element describes a set of | ||||
civic addresses that fall within the service boundary, namely all | ||||
addresses that textually match the civic address elements provided, | ||||
regardless of the value of other address elements. A location falls | ||||
within the mapping's service boundary if it matches any of the | ||||
<serviceBoundary> elements. | ||||
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 | |||
thus be quite large, clients may opt to conserve bandwidth and | can thus be quite large, clients may wish to conserve bandwidth by | |||
request 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 8) 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 per 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 the remainder of the mapping has become invalid. | the remainder of the mapping has become invalid. | |||
5.7. The Service Number 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: <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. The <via> | received the request from the client issuing the request. The <via> | |||
element is inserted logically on receipt of the request, so that | element is inserted logically on receipt of the request, so that | |||
every server in a recursive query operation is included in the <path> | every server in a recursive query operation is included in the <path> | |||
element. | element. | |||
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 | ||||
together with the mapping is returned. | ||||
The example in Figure 5 indicates that the answer was given to the | The example in Figure 5 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. Mapping a Location and Service to URLs: <findService> | 7. Identifying the Location Element Used for Mapping: <locationUsed> | |||
7.1. Overview | Several of the requests can provide one or more <location> elements, | |||
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 | ||||
result. For that purpose, the <location> tag MUST contain an 'id' | ||||
attribute that uniquely identifies the <location> element. The | ||||
format of the identifier is left to the client; it could, for | ||||
example, use a hash of the location information. The server returns | ||||
the identifier for the <location> element it used in the | ||||
<locationUsed> tag. | ||||
8. Mapping a Location and Service to URLs: <findService> | ||||
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. | |||
7.2. Examples | 8.2. Examples | |||
7.2.1. Example Using Geodetic Coordinates | 8.2.1. Example Using Geodetic Coordinates | |||
The following is an example of mapping a service to a location using | The following is an example of mapping a service to a location using | |||
geodetic coordinates, for the service associated with the police | geodetic coordinates, for the service associated with the police | |||
(urn:service:sos.police). | (urn:service:sos.police). | |||
<?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" | |||
serviceBoundary="value" | serviceBoundary="value" | |||
recursive="true"> | recursive="true"> | |||
<location 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 2: 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 Deparment, instructing the client | service to the New York City Police Department, instructing the | |||
that it may contact them via the URIs "sip:nypd@example.com" and | client that it may contact them via the URIs "sip:nypd@example.com" | |||
"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 | |||
the expiration time has been reached, it may want to requery for this | the expiration time has been reached, it may want to requery for this | |||
information, depending on the usage environment of LoST. | information, depending on the usage environment of LoST. | |||
<?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" version="1"> | sourceId="7e3f40b098c711dbb6060800200c9a66"> | |||
<displayName xml:lang="en"> | <displayName xml:lang="en"> | |||
New York City Police Department | New York City Police Department | |||
</displayName> | </displayName> | |||
<service>urn:service:sos.police</service> | <service>urn:service:sos.police</service> | |||
<serviceBoundary profile="geodetic-2d"> | <serviceBoundary profile="geodetic-2d"> | |||
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | |||
<p2:exterior> | <p2:exterior> | |||
<p2:LinearRing> | <p2:LinearRing> | |||
<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> | |||
skipping to change at page 16, line 35 | skipping to change at page 17, line 35 | |||
<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> | |||
<uri>xmpp:nypd@example.com</uri> | <uri>xmpp:nypd@example.com</uri> | |||
<serviceNumber>911</serviceNumber> | <serviceNumber>911</serviceNumber> | |||
</mapping> | </mapping> | |||
<path> | <path> | |||
<via source="authoritative.example"/> | ||||
<via source="resolver.example"/> | <via source="resolver.example"/> | |||
<via source="authoritative.example"/> | ||||
</path> | </path> | |||
<locationUsed id="6020688f1ce1896d"/> | ||||
</findServiceResponse> | </findServiceResponse> | |||
Figure 3: A <findServiceResponse> geodetic answer | Figure 3: A <findServiceResponse> geodetic answer | |||
7.2.2. Civic Address Mapping Example | 8.2.2. Civic Address Mapping Example | |||
The following is an example of mapping a service to a location much | The example below shows how to map a service to a location much like | |||
like the example in Section 7.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). | |||
<?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 | <location id="627b8bf819d0bad4d" profile="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>Germany</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> | |||
skipping to change at page 18, line 11 | skipping to change at page 19, line 11 | |||
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 city 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" version="1" > | 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="urn:ietf:params:lost:location-profile:basic-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>Germany</country> | |||
<A1>Bavaria</A1> | <A1>Bavaria</A1> | |||
skipping to change at page 18, line 34 | skipping to change at page 19, line 34 | |||
</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> | |||
<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"/> | ||||
</findServiceResponse> | </findServiceResponse> | |||
Figure 5: A <findServiceResponse> civic address answer | Figure 5: A <findServiceResponse> civic address answer | |||
7.3. Components of the <findService> Request | 8.3. Components of the <findService> Request | |||
The <findService> request includes attributes that govern whether the | The <findService> request includes attributes that govern whether the | |||
request is handled iteratively or recursively, whether location | request is handled iteratively or recursively, whether location | |||
validation is performed and which elements may be contained in the | validation is performed and which elements may be contained in the | |||
response. | response. | |||
7.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 11). 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 objects is | for each distinct location profile. The order of location elements | |||
significant; the server uses the first location object where it | is significant; the server uses the first location element where it | |||
understands the location profile. | understands the location profile. | |||
7.3.2. Identifying the Service: The <service> Element | 8.3.2. Identifying the Service: The <service> Element | |||
The type of service desired is specified by the <service> element. | The type of service desired is specified by the <service> element. | |||
It contains service URNs from the registry established in [9]. | It contains service URNs from the registry established in [9]. | |||
7.3.3. Recursion and Iteration | 8.3.3. Recursion and Iteration | |||
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. | response indicating the next server to be queried if the server | |||
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 LoST <findService> and | |||
<listServicesByLocation> queries can be recursive, as indicated by | <listServicesByLocation> queries can be recursive, as indicated by | |||
the 'recursive' attribute. A value of "true" indicates a recursive | the 'recursive' attribute. A value of "true" indicates a recursive | |||
query, with the default being "false" when the attribute is omitted. | query, with the default being "false" when the attribute is omitted. | |||
Regardless of the attribute, a server MAY always answer a query by | Regardless of the attribute, a server MAY always answer a query by | |||
providing a LoST application unique string (see Section 4), i.e., | providing a LoST application unique string (see Section 4), i.e., | |||
indirection, however, it MUST NOT recurse if the attribute is | indirection, however, it MUST NOT recurse if the attribute is | |||
"false". | "false". | |||
7.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 | |||
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. | |||
7.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 7.4.2. The example in Figure 6 demonstrates address | Section 8.4.2. The example in Figure 6 demonstrates address | |||
validation, omitting the standard response elements. | validation. If the server chooses a geodetic location among the | |||
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 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>DE</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> | |||
Figure 6: A <findService> query with address validation request | Figure 6: 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"> | |||
version="1" > | ||||
<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>Germany</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> | |||
<valid>country A1 A3 A6</valid> | <valid>country A1 A3 A6</valid> | |||
<invalid>PC</invalid> | <invalid>PC</invalid> | |||
<unchecked>HNO</unchecked> | ||||
</locationValidation> | </locationValidation> | |||
<path> | <path> | |||
<via source="authoritative.example"/> | ||||
<via source="resolver.example"/> | <via source="resolver.example"/> | |||
<via source="authoritative.example"/> | ||||
</path> | </path> | |||
<locationUsed id="627b8bf819d0bad4d"/> | ||||
</findServiceResponse> | </findServiceResponse> | |||
Figure 7: A <findServiceResponse> message with address validation | Figure 7: A <findServiceResponse> message with address validation | |||
information | information | |||
7.4. Components of the Mapping Response <findServiceResponse> | 8.4. Components of the Mapping Response <findServiceResponse> | |||
7.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 12.2), location validation information (Section 7.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. | |||
7.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 white | |||
space, enumerating the civic location lables used in child elements | space, enumerating the civic location labels used in child elements | |||
of the <civicAddress> element. The <valid> element enumerates those | of the <civicAddress> element. The <valid> element enumerates those | |||
civic address elements that have been recognized as valid by the LoST | civic address elements that have been recognized as valid by the LoST | |||
server and that have been used to determine the mapping. The | server and that have been used to determine the mapping. The | |||
<unchecked> elements enumerates the civic address elements that the | <unchecked> elements enumerates the civic address elements that the | |||
server did not check and that were not used in determining the | server did not check and that were not used in determining the | |||
response. The <invalid> element enumerate civic address elements | response. The <invalid> element enumerate civic address elements | |||
that the server attempted to check, but that did not match the other | that the server attempted to check, but that did not match the other | |||
civic address elements found in the <valid> list. | civic address elements found in the <valid> list. Civic location | |||
tokens that are neither listed in the <valid>, the <invalid> and the | ||||
<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 (Figure 6) indicates that the tokens 'country', 'A1', | The example shown in Figure 6 and in Figure 7 indicates that the | |||
'A3', and 'A6' have been validated by the LoST server. The server | tokens 'country', 'A1', 'A3', and 'A6' have been validated by the | |||
considered the postal code 81675 in the <PC> element as not valid for | LoST server. The server considered the postal code 81675 in the <PC> | |||
this location. | element as not valid for this location. The 'HNO' token belongs to | |||
the class of unchecked location tokens. | ||||
8. 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. | the boundary by value. This is shown in the example in Figure 8 and | |||
The client can then retrieve the boundary using the | Figure 9. 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 10. The client issues the request to the server identified in | Figure 10. The client issues the request to the server identified in | |||
the 'server' attribute of the <serviceBoundaryReference> element. | the 'server' attribute of the <serviceBoundaryReference> element. | |||
These requests are always directed to the authoritative server and do | These requests are always directed to the authoritative server and do | |||
not recurse. | 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 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 8: <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"> | |||
version="1"> | ||||
<displayName xml:lang="en"> | <displayName xml:lang="en"> | |||
New York City Police Department | New York City Police Department | |||
</displayName> | </displayName> | |||
<service>urn:service:sos.police</service> | <service>urn:service:sos.police</service> | |||
<serviceBoundaryReference | <serviceBoundaryReference | |||
source="authoritative.example" | source="authoritative.example" | |||
key="7214148E0433AFE2FA2D48003D31172E" /> | key="7214148E0433AFE2FA2D48003D31172E" /> | |||
<uri>sip:nypd@example.com</uri> | <uri>sip:nypd@example.com</uri> | |||
<uri>xmpp:nypd@example.com</uri> | <uri>xmpp:nypd@example.com</uri> | |||
<serviceNumber>911</serviceNumber> | <serviceNumber>911</serviceNumber> | |||
</mapping> | </mapping> | |||
<path> | <path> | |||
<via source="authoritative.example"/> | ||||
<via source="resolver.example"/> | <via source="resolver.example"/> | |||
<via source="authoritative.example"/> | ||||
</path> | </path> | |||
<locationUsed id="6020688f1ce1896d"/> | ||||
</findServiceResponse> | </findServiceResponse> | |||
Figure 9: <findServiceResponse> message with service boundary | Figure 9: <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 10: 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 11. | |||
<?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 | <serviceBoundary profile="civic"> | |||
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="authoritative.example"/> | ||||
<via source="resolver.example"/> | <via source="resolver.example"/> | |||
<via source="authoritative.example"/> | ||||
</path> | </path> | |||
</getServiceBoundaryResponse> | </getServiceBoundaryResponse> | |||
Figure 11: Civic Address Service Boundary Response | Figure 11: Civic Address Service Boundary Response | |||
9. 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 10) 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 12. | |||
<?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 12: Example of <ListServices> query | |||
skipping to change at page 27, line 5 | skipping to change at page 28, line 5 | |||
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 | urn:service:sos.suicide | |||
</serviceList> | </serviceList> | |||
</listServicesResponse> | </listServicesResponse> | |||
Figure 13: Example of <ListServiceResponse> | Figure 13: Example of <ListServiceResponse> | |||
10. 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 11), 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. By its nature, the query can only indicate the services | request. The query indicates the services that the server can | |||
that a particular server can determine, not all possible services | enumerate from within the forest structure of which it is a part. | |||
that might be offered. Unlike <ListServices>, the answer describes | Because LoST does not presume a single, overarching organization of | |||
the services available at a specific location, not just those | all potential service types, there may be services available within a | |||
understood by the server. | geographic area which could be described by other LoST servers | |||
connected to other forest structures. As an example, the emergency | ||||
services forest for a region may be distinct from the forests that | ||||
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> | |||
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 14 and in Figure 15, | |||
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 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 14: Example of <ListServicesbyLocation> query | |||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<listServicesByLocationResponse | <listServicesByLocationResponse | |||
skipping to change at page 28, line 20 | skipping to change at page 29, line 20 | |||
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 | urn:service:sos.suicide | |||
</serviceList> | </serviceList> | |||
<path> | <path> | |||
<via source="authoritative.example"/> | ||||
<via source="resolver.example"/> | <via source="resolver.example"/> | |||
<via source="authoritative.example"/> | ||||
</path> | </path> | |||
<locationUsed id="3e19dfb3b9828c3"/> | ||||
</listServicesByLocationResponse> | </listServicesByLocationResponse> | |||
Figure 15: Example of <ListServices> response | Figure 15: Example of <ListServices> response | |||
11. 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 | |||
define the manner in which location information is transmitted. It | define the manner in which location information is transmitted. It | |||
possible to standardize other profiles in the future. The two | is possible to standardize other profiles in the future. The three | |||
baseline profiles are: | baseline profiles are: | |||
geodetic-2d: | geodetic-2d: | |||
a simple profile for two-dimensional geodetic location | a profile for two-dimensional geodetic location information, as | |||
information, as described in Section 11.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 11.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 | |||
profile MUST define: | profile MUST define: | |||
skipping to change at page 30, line 5 | skipping to change at page 31, line 5 | |||
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. | |||
11.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 16.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 a mandatory 'profile' attribute that | <location> element carries an optional 'profile' attribute that | |||
indicates the location format of the child elements. The concept of | indicates the location format of the child elements. A client may | |||
location profiles are described in Section 11. With the ability to | obtain location information that does not conform to a profile it | |||
specify more than one <location> element the client is able to convey | recognizes or it may not have the capability to map XML to profiles. | |||
location information for multiple location profiles in the same | In that case, a client MAY omit the profile attribute and the server | |||
request. | should interpret the XML location data to the best of its ability, | |||
returning a "locationProfileUnrecognized" error if it is unable to do | ||||
so. | ||||
The concept of location profiles are described in Section 12. With | ||||
the ability to specify more than one <location> element the client is | ||||
able to convey location information for multiple location profiles 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 conformant to the location profile | contains location information conforming to the location profile | |||
specified in the 'profile' attribute. When multiple <location> | specified in the 'profile' attribute. A response MAY contain | |||
elements are included then it enables the server to send location | multiple mappings or boundaries for the different <location> | |||
information compliant with multiple location profiles. | 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 | |||
rules insure basic interoperatiblity between clients and servers: | rules ensure interoperability between clients and servers: | |||
1. A client MUST be capable of understanding the response for the | 1. A client MUST be capable of understanding the response for the | |||
baseline profiles it used in the request. | baseline profiles it used in the request. | |||
2. If a client sends location information conformant to any location | 2. If a client sends location information conformant to any location | |||
profile other than geodetic-2d or civic, it MUST also send, in | profile other than the ones described in this document, it MUST | |||
the same request, location information conformant to one of the | also send, in the same request, location information conformant | |||
baseline profiles. Otherwise, the server might not be able to | to one of the baseline profiles. Otherwise, the server might not | |||
understand the request. | be able to understand the request. | |||
3. A client SHOULD NOT send multiple <location> profiles of derived | 3. A client MUST NOT send multiple <location> objects that are | |||
from different baseline profiles. Or said another way, a client | derived from different baseline profiles. In other words, a | |||
should only send location profiles from the same baseline profile | client MUST only send location objects according to the same | |||
in the same query. If a client has location information | baseline profile in a query, but it MAY contain a location | |||
primarily of geodetic nature and location information primarily | element following a baseline profile in addition to some other | |||
of a civic nature, it should send separate requests containing | profile. | |||
each type of location information. | ||||
4. There can only be one instance of each location profile in a | 4. If a client has both location information primarily of geodetic | |||
nature and location information primarily of a civic nature, it | ||||
MUST send separate requests containing each type of location | ||||
information. | ||||
5. There can only be one instance of each location profile in a | ||||
query. | query. | |||
5. Servers MUST implement the geodetic-2d and civic profiles. | 6. Servers MUST implement all profiles described in this document. | |||
6. A server uses the first-listed location profile that it | 7. A server uses the first-listed location profile that it | |||
understands and ignores the others. | understands and ignores the others. | |||
7. 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 12.1). | responds with a <locationProfileError> (Section 13.1). | |||
8. 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. Client X has had its firmware upgraded to support the | |||
uber-complex-3D location profile. Client X sends location | 'not-yet-standardized-prism-profile' location profile. Client X | |||
information to Server Y, which does not understand the | sends location information to Server Y, which does not understand the | |||
uber-complex-3D location profile. If Client X also sends location | 'not-yet-standardized-prism-profile' location profile. If Client X | |||
information using the geodetic-2D baseline profile, then Server Y | also sends location information using the geodetic-2D baseline | |||
will still be able to understand the request and provide an | profile, then Server Y will still be able to understand the request | |||
understandable response, though with location information that might | and provide an understandable response, though with location | |||
not be as precise or expressive as desired. This is possible because | information that might not be as precise or expressive as desired. | |||
both Client X and Server Y understand the baseline profile. | This is possible because both Client X and Server Y 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:p2="http://www.opengis.net/gml" | xmlns:gml="http://www.opengis.net/gml" | |||
xmlns:gs="http://www.opengis.net/pidflo/1.0" | ||||
recursive="true" | recursive="true" | |||
serviceBoundary="value"> | serviceBoundary="value"> | |||
<location profile="uber-complex-3d"> | <location profile="not-yet-standardized-prism-profile"> | |||
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> | <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"> | |||
<p2:pos>37.775 -122.422</p2:pos> | <gs:base> | |||
</p2:Point> | <gml:Polygon> | |||
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | <gml:exterior> | |||
<p2:exterior> | <gml:LinearRing> | |||
<p2:LinearRing> | <gml:posList> | |||
<p2:pos>37.775 -122.4194</p2:pos> | 42.556844 -73.248157 36.6 | |||
<p2:pos>37.555 -122.4194</p2:pos> | 42.656844 -73.248157 36.6 | |||
<p2:pos>37.555 -122.4264</p2:pos> | 42.656844 -73.348157 36.6 | |||
<p2:pos>37.775 -122.4264</p2:pos> | 42.556844 -73.348157 36.6 | |||
<p2:pos>37.775 -122.4194</p2:pos> | 42.556844 -73.248157 36.6 | |||
</p2:LinearRing> | </gml:posList> | |||
</p2:exterior> | </gml:LinearRing> | |||
</p2:Polygon> | </gml:exterior> | |||
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> | </gml:Polygon> | |||
<p2:pos>-122.422 37.775</p2:pos> | </gs:base> | |||
</p2:Point> | <gs:height uom="urn:ogc:def:uom:EPSG::9001"> | |||
2.4 | ||||
</gs:height> | ||||
</gs:Prism> | ||||
</location> | </location> | |||
<location profile="geodetic-2d"> | <location profile="geodetic-2d"> | |||
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326"> | <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> | |||
<p2:pos>37.775 -122.422</p2:pos> | <gml:pos>42.656844 -73.348157</gml:pos> | |||
</p2: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 16: 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"> | |||
version="1"> | ||||
<displayName xml:lang="en"> | <displayName xml:lang="en"> | |||
New York City Police Department | New York City Police Department | |||
</displayName> | </displayName> | |||
<service>urn:service:sos.police</service> | <service>urn:service:sos.police</service> | |||
<serviceBoundary profile="geodetic-2d"> | <serviceBoundary profile="geodetic-2d"> | |||
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | |||
<p2:exterior> | <p2:exterior> | |||
<p2:LinearRing> | <p2:LinearRing> | |||
<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> | |||
</mapping> | </mapping> | |||
<path> | <path> | |||
<via source="authoritative.example"/> | ||||
<via source="resolver.example"/> | <via source="resolver.example"/> | |||
<via source="authoritative.example"/> | ||||
</path> | </path> | |||
<locationUsed id="6020688f1ce1896d"/> | ||||
</findServiceResponse> | </findServiceResponse> | |||
Figure 17: Example of a <findServiceResponse> message with baseline | Figure 17: Example of a <findServiceResponse> message with baseline | |||
profile interoperability | profile interoperability | |||
11.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 use this profile by placing a <Point> element, as described | Clients and servers use this profile by placing the following | |||
in Section 7.2.1 of [13], within the <location> element. Section | location shapes into the <serviceBoundary> or into the <location> | |||
7.2.1 of [13] describes the specification of a <Point> with either a | element (unless indicated otherwise): | |||
two dimensional position (latitude and longitude) or three | ||||
dimensional position (latitude, longitude, and altitude). A client | ||||
MAY use the three dimensional position, and servers MAY interpret a | ||||
three dimensional position as a two dimensional position by ignoring | ||||
altitude. | ||||
Servers use this profile by placing a <Polygon> element, as described | Point: | |||
in Section 7.2.2 of [13], within the <serviceBoundary> element. This | ||||
is defined by the 'polygon' pattern in the LoST schema (see | ||||
Section 14). | ||||
With respect to the description in Section 7.2.2 of [13] the | The <Point> element is described in Section 5.2.1 of [13]. | |||
restriction to 16 points for a polygon is not applicable to this | Section 5.2.1 of [13] shows also the specification of a <Point> | |||
document. With this profile servers MUST use WGS 84 (latitude, | with either a two dimensional position (latitude and longitude) or | |||
longitude), i.e., the srsName set to 'urn:ogc:def:crs:EPSG::4326' | three dimensional position (latitude, longitude, and altitude). A | |||
where altitude information is omitted. The orientation of the points | client MAY use the three dimensional position, and servers MAY | |||
in the polygon is upward normal as described in Section 7.2.2 of | interpret a three dimensional position as a two dimensional | |||
[13]. | position by ignoring the altitude value. A <Point> element is not | |||
placed into a <serviceBoundary> element. | ||||
11.3. Basic Civic Profile | Polygon: | |||
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 | ||||
of [12] is not applicable to this document. | ||||
Circle: | ||||
The <Circle> element is described in Section 5.2.3 of [13]. | ||||
Ellipse: | ||||
The <Ellipse> element is described in Section 5.2.4 of [13]. | ||||
ArcBand: | ||||
The <ArcBand> element is described in Section 5.2.5 of [13]. | ||||
When clients place a <Polygon>, <Circle>, <Ellipse> or <ArcBand> | ||||
element within the <location> element then it indicates that the | ||||
query is about any point contained in the given area; it is left to | ||||
the server to select an appropriate matching algorithm, such as using | ||||
computing the centroid. A server MAY return multiple <mapping> | ||||
elements if the polygon extends across multiple service areas. | ||||
When geodetic location information of this location profile is placed | ||||
in the <serviceBoundary> element then the elements with geospatial | ||||
coordinates are alternative descriptions of the same service region, | ||||
not additive geometries. | ||||
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. | |||
12. Errors, Warnings, and Redirects | A response MAY contain more than one <serviceBoundary> element with | |||
profile 'civic'. Each <serviceBoundary> element describes a set of | ||||
civic addresses that fall within the service boundary, namely all | ||||
addresses that textually match the civic address elements provided, | ||||
regardless of the value of other address elements. A location falls | ||||
within the mapping's service boundary if it matches any of the | ||||
<serviceBoundary> elements. Hence, a response may contain multiple | ||||
<serviceBoundary> elements with civic and/or geodetic location | ||||
profiles. | ||||
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 error 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. This document | response may not be quite what the client had desired. For both | |||
does not define warnings. For both elements, the 'source' attribute | elements, the 'source' attribute names the server that originally | |||
names the server that originally generated the error or warning, such | generated the error or warning, such as the authoritative server. | |||
as the authoritative server. Unless otherwise noted, all elements | Unless otherwise noted, all elements below can be either an error or | |||
below can be either an error or a warning, depending on whether a | a warning, depending on whether a default response, such as a | |||
default response, such as a mapping, is included. | mapping, is included. | |||
12.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. (For HTTP as the underlying | authoritative server and was refused. | |||
protocol, an HTTP 401 error would be returned.) | ||||
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 11). | (see Section 12). | |||
locationInvalid | ||||
The geodetic or civic location in the request was invalid. For | ||||
example, the longitude or latitude values fall outside the | ||||
acceptable ranges. | ||||
SRSInvalid | ||||
The spatial reference system (SRS) contained in the location | ||||
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. | |||
skipping to change at page 36, line 40 | skipping to change at page 39, line 13 | |||
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 18: Example of an error resonse | |||
12.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 | ||||
content negotiation capabilities (see Section 14) MAY be utilized by | ||||
a server. | ||||
This version of the specification does not define any warning | This version of the specification defines the following warnings: | |||
elements. | ||||
12.3. Redirects | locationValidationUnavailable | |||
The <locationValidationUnavailable> element MAY be returned when a | ||||
server wishes to notify a client that it cannot fulfill a location | ||||
validation request. This warning allows a server to return | ||||
mapping information while signalling this exception state. | ||||
serviceSubstitution | ||||
The <serviceSubstitution> element MAY be returned when a server | ||||
was not able to fulfill a <findService> request for a given | ||||
service URN. For example, a <findService> request with the | ||||
'urn:service:sos.police' service URN for a location in Uruguay may | ||||
cause the LoST service to return a mapping for the | ||||
'urn:service:sos' service URN since Uruguay does not make use of | ||||
the sub-services police, fire and ambulance. If this warning is | ||||
returned then the <service> element in the response provides | ||||
information about the service URN that refers to the mapping. | ||||
defaultMappingReturned | ||||
The <defaultMappingReturned> element MAY be returned when a server | ||||
was not able to fulfill a <findService> request for a given | ||||
location but is able to respond with a default URI. For example, | ||||
a nearby PSAP may be returned. | ||||
An example of a warning is shown below: | ||||
<?xml version="1.0" encoding="UTF-8"?> | ||||
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" | ||||
xmlns:p2="http://www.opengis.net/"> | ||||
<mapping | ||||
expires="2007-01-01T01:44:33Z" | ||||
lastUpdated="2006-11-01T01:00:00Z" | ||||
source="authoritative.example" | ||||
sourceId="fb8ed888433343b7b27865aeb38f3a99"> | ||||
<displayName xml:lang="en"> | ||||
New York City Police Department | ||||
</displayName> | ||||
<service>urn:service:sos.police</service> | ||||
<serviceBoundary profile="geodetic-2d"> | ||||
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | ||||
<p2:exterior> | ||||
<p2:LinearRing> | ||||
<p2:pos>37.775 -122.4194</p2:pos> | ||||
<p2:pos>37.555 -122.4194</p2:pos> | ||||
<p2:pos>37.555 -122.4264</p2:pos> | ||||
<p2:pos>37.775 -122.4264</p2:pos> | ||||
<p2:pos>37.775 -122.4194</p2:pos> | ||||
</p2:LinearRing> | ||||
</p2:exterior> | ||||
</p2:Polygon> | ||||
</serviceBoundary> | ||||
<uri>sip:nypd@example.com</uri> | ||||
</mapping> | ||||
<warnings source="authoritative.example"> | ||||
<defaultMappingReturned | ||||
message="Unable to determine PSAP for the given location; | ||||
using default PSAP" | ||||
xml:lang="en"/> | ||||
</warnings> | ||||
<path> | ||||
<via source="resolver.example"/> | ||||
<via source="authoritative.example"/> | ||||
</path> | ||||
</findServiceResponse> | ||||
Figure 19: Example of an warning resonse | ||||
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. | |||
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 resonse | Figure 20: Example of a redirect response | |||
13. LoST Transport | 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; other mechanisms are left to future | |||
documents. The available transport mechanisms are determined through | documents. The available transport mechanisms are determined through | |||
the use of the LoST U-NAPTR application. In protocols that support | the use of the LoST U-NAPTR application. In protocols that support | |||
content type indication, LoST uses the media type application/ | content type indication, LoST uses the media type application/ | |||
lost+xml. | 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. All HTTP responses are applicable. The HTTP URL is | POST method. The HTTP request MUST use the Cache-Control response | |||
derived from the LoST server name via U-NAPTR application, as | directive "no-cache" to HTTP-level "caching even by caches that have | |||
discussed above | been configured to return stale responses to client requests." | |||
14. Relax NG Schema | All LoST responses, including those indicating a LoST warning or | |||
error, are carried in 2xx responses, typically 200 (OK). Other 2xx | ||||
responses, in particular 203 (Non-authoritative information) may be | ||||
returned by HTTP caches that disregard the caching instructions. 3xx, | ||||
4xx and 5xx HTTP response codes indicates that the HTTP request | ||||
itself failed or was redirected; these responses do not contain any | ||||
LoST XML elements. | ||||
The HTTP URL is derived from the LoST server name via U-NAPTR | ||||
application, as discussed above. | ||||
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 LoST protocol in | |||
the compact form. The verbose form is included in Appendix A. | 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 Protocol (LoST) | |||
## | ## | |||
skipping to change at page 41, line 5 | skipping to change at page 45, line 5 | |||
div { | div { | |||
commonResponsePattern = warnings*, path, extensionPoint | commonResponsePattern = warnings*, path, extensionPoint | |||
} | } | |||
## | ## | |||
## Location Information | ## Location Information | |||
## | ## | |||
div { | div { | |||
locationInformation = | locationInformation = | |||
extensionPoint+, | extensionPoint+, | |||
attribute profile { xsd:NMTOKEN } | attribute profile { xsd:NMTOKEN }? | |||
} | } | |||
## | ## | |||
## Service Boundary | ## Service Boundary | |||
## | ## | |||
div { | div { | |||
serviceBoundary = element serviceBoundary { locationInformation }+ | serviceBoundary = element serviceBoundary { locationInformation }+ | |||
} | } | |||
## | ## | |||
skipping to change at page 42, line 47 | skipping to change at page 46, line 47 | |||
element invalid { qnameList }?, | element invalid { qnameList }?, | |||
element unchecked { qnameList }?, | element unchecked { qnameList }?, | |||
extensionPoint | extensionPoint | |||
} | } | |||
} | } | |||
## | ## | |||
## Errors and Warnings Container. | ## Errors and Warnings Container. | |||
## | ## | |||
div { | div { | |||
errorContainer = | exceptionContainer = | |||
(badRequest? | (badRequest? | |||
& internalError? | & internalError? | |||
& serviceSubstitution? | & serviceSubstitution? | |||
& defaultMappingReturned? | ||||
& forbidden? | & forbidden? | |||
& notFound? | & notFound? | |||
& loop? | & loop? | |||
& serviceNotImplemented? | & serviceNotImplemented? | |||
& serverTimeout? | & serverTimeout? | |||
& serverError? | & serverError? | |||
& locationInvalid? | ||||
& locationProfileUnrecognized?), | & locationProfileUnrecognized?), | |||
extensionPoint, | extensionPoint, | |||
source | source | |||
errors = element errors { errorContainer } | errors = element errors { exceptionContainer } | |||
warnings = element warnings { errorContainer } | warnings = element warnings { exceptionContainer } | |||
} | } | |||
## | ## | |||
## Basic Errors | ## Basic Exceptions | |||
## | ## | |||
div { | div { | |||
## | ## | |||
## Error pattern. | ## Exception pattern. | |||
## | ## | |||
basicError = message, extensionPoint | basicException = message, extensionPoint | |||
badRequest = element badRequest { basicError } | badRequest = element badRequest { basicException } | |||
internalError = element internalError { basicError } | internalError = element internalError { basicException } | |||
serviceSubstitution = element serviceSubstitution { basicError } | serviceSubstitution = element serviceSubstitution { basicException } | |||
forbidden = element forbidden { basicError } | defaultMappingReturned = | |||
notFound = element notFound { basicError } | element defaultMappingReturned { basicException } | |||
loop = element loop { basicError } | forbidden = element forbidden { basicException } | |||
serviceNotImplemented = element serviceNotImplemented { basicError } | notFound = element notFound { basicException } | |||
serverTimeout = element serverTimeout { basicError } | loop = element loop { basicException } | |||
serverError = element serverError { basicError } | serviceNotImplemented = | |||
element serviceNotImplemented { basicException } | ||||
serverTimeout = element serverTimeout { basicException } | ||||
serverError = element serverError { basicException } | ||||
locationInvalid = element locationInvalid { basicException } | ||||
locationValidationUnavailable = | ||||
element locationValidationUnavailable { basicException } | ||||
locationProfileUnrecognized = | locationProfileUnrecognized = | |||
element locationProfileUnrecognized { | element locationProfileUnrecognized { | |||
attribute unsupportedProfiles { xsd:NMTOKENS }, | attribute unsupportedProfiles { xsd:NMTOKENS }, | |||
basicError | basicException | |||
} | } | |||
} | } | |||
## | ## | |||
## Redirect. | ## Redirect. | |||
## | ## | |||
div { | div { | |||
## | ## | |||
## Redirect pattern | ## Redirect pattern | |||
## | ## | |||
redirect = | redirect = | |||
element redirect { | element redirect { | |||
attribute target { appUniqueString }, | attribute target { appUniqueString }, | |||
source, | source, | |||
message, | message, | |||
extensionPoint | extensionPoint | |||
} | } | |||
skipping to change at page 44, line 45 | skipping to change at page 49, line 4 | |||
notLost = element * - (ns1:* | ns1:*) { anyElement } | notLost = element * - (ns1:* | ns1:*) { anyElement } | |||
## | ## | |||
## A wildcard pattern for including any element | ## A wildcard pattern for including any element | |||
## from any other namespace. | ## from any other namespace. | |||
## | ## | |||
anyElement = | anyElement = | |||
(element * { anyElement } | (element * { anyElement } | |||
| attribute * { text } | | attribute * { text } | |||
| 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 20: RelaxNG schema | Figure 21: RelaxNG schema | |||
15. Internationalization Considerations | 16. Internationalization Considerations | |||
This mechanism is largely for passing protocol information from one | The LoST protocol is mostly meant for machine-to-machine | |||
subsystem to another; as such, most of its elements are tokens not | communications; as such, most of its elements are tokens not meant | |||
meant for direct human consumption. If these tokens are presented to | for direct human consumption. If these tokens are presented to the | |||
the end user, some localization may need to occur. The content of | end user, some localization may need to occur. The content of the | |||
the <displayName> element and the 'message' attributes may be | <displayName> element and the 'message' attributes may be displayed | |||
displayed to the end user, and they are thus a complex types designed | to the end user, and they are thus complex types designed for this | |||
for this purpose. | purpose. | |||
LoST exchanges information using XML. All XML processors are | LoST exchanges information using XML. All XML processors are | |||
required to understand UTF-8 and UTF-16 encodings, and therefore all | required to understand UTF-8 and UTF-16 encodings, and therefore all | |||
LoST clients and servers MUST understand UTF-8 and UTF-16 encoded | LoST clients and servers MUST understand UTF-8 and UTF-16 encoded | |||
XML. Additionally, LoST servers and clients MUST NOT encode XML with | XML. Additionally, LoST servers and clients MUST NOT encode XML with | |||
encodings other than UTF-8 or UTF-16. | encodings other than UTF-8 or UTF-16. | |||
16. IANA Considerations | 17. IANA Considerations | |||
16.1. U-NAPTR Registrations | 17.1. U-NAPTR Registrations | |||
This document registers the following U-NAPTR application service | This document registers the following U-NAPTR application service | |||
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 | |||
skipping to change at page 47, line 32 | skipping to change at page 51, line 32 | |||
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] | |||
16.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 | |||
Optional parameters: charset | Optional parameters: charset | |||
Indicates the character encoding of enclosed XML. | Indicates the character encoding of enclosed XML. | |||
Encoding considerations: | Encoding considerations: Uses XML, which can employ 8-bit | |||
characters, depending on the character encoding used. See RFC | ||||
Uses XML, which can employ 8-bit characters, depending on the | 3023 [5], Section 3.2. | |||
character encoding used. See RFC 3023 [5], Section 3.2. | ||||
Security considerations: | ||||
This content type is designed to carry LoST protocol payloads. | Security considerations: This content type is designed to carry LoST | |||
protocol payloads. | ||||
Interoperability considerations: None | Interoperability considerations: None | |||
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please | Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please | |||
replace XXXX with the RFC number of this specification.] this | replace XXXX with the RFC number of this specification.] | |||
document | ||||
Applications which use this media type: | ||||
Emergency and Location-based Systems | Applications which use this media type: Emergency and Location-based | |||
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: Hannes | |||
Tschofenig, Hannes.Tschofenig@siemens.com | 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> | |||
16.3. LoST Relax NG Schema Registration | 17.3. LoST Relax NG Schema Registration | |||
URI: urn:ietf:params:xml:ns:lost1 | URI: urn:ietf:params:xml:ns:lost1 | |||
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | |||
(Hannes.Tschofenig@siemens.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 | |||
in Section 14. Its first line is | in Section 15. Its first line is | |||
default namespace = "urn:ietf:params:xml:ns:lost1" | default namespace = "urn:ietf:params:xml:ns:lost1" | |||
and its last line is | and its last line is | |||
} | } | |||
16.4. LoST Namespace Registration | 17.4. LoST Namespace Registration | |||
URI: urn:ietf:params:xml:ns:lost1 | URI: urn:ietf:params:xml:ns:lost1 | |||
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | |||
(Hannes.Tschofenig@siemens.com). | (Hannes.Tschofenig@nsn.com). | |||
XML: | XML: | |||
BEGIN | BEGIN | |||
<?xml version="1.0"?> | <?xml version="1.0"?> | |||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" | |||
"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" | |||
skipping to change at page 50, line 6 | skipping to change at page 54, line 6 | |||
<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="[URL of published RFC]">RFCXXXX | |||
[NOTE TO IANA/RFC-EDITOR: | [NOTE TO IANA/RFC-EDITOR: | |||
Please replace XXXX with the RFC number of this | Please replace XXXX with the RFC number of this | |||
specification.]</a>.</p> | specification.]</a>.</p> | |||
</body> | </body> | |||
</html> | </html> | |||
END | END | |||
16.5. LoST Location Profile Registry | 17.5. LoST Location Profile Registry | |||
This document seeks to create a registry of location profile names | This document seeks to create a registry of location profile names | |||
for the LoST protocol. Profile names are XML tokens. This registry | for the LoST protocol. Profile names are XML tokens. This registry | |||
will operate in accordance with RFC 2434 [2], Standards Action. | will operate in accordance with RFC 2434 [2], Standards Action. | |||
geodetic-2d: | geodetic-2d: | |||
Defined in Section 11.2 | Defined in Section 12.2. | |||
civic: | civic: | |||
Defined in Section 11.3 | Defined in Section 12.3. | |||
17. Security Considerations | 18. Security Considerations | |||
There are multiple 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, the use | To avoid that an attacker can modify the query or its result, the use | |||
of channel security, such as TLS, is RECOMMENDED. | of channel security, such as TLS, is RECOMMENDED. | |||
Generally, authentication and authorization is not required for | Generally, authentication and authorization is not required for | |||
mapping queries. If it is, authentication mechanism of the | mapping queries. If it is, authentication mechanism of the | |||
underlying transport mechanism, such as HTTP basic and digest | underlying transport mechanism, such as HTTP basic and digest | |||
authentication, MAY be used. (Basic authentication SHOULD only be | authentication, MAY be used. (Basic authentication SHOULD only be | |||
used 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 are | |||
provided in [17]. | provided in [17]. | |||
18. 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) | |||
skipping to change at page 52, line 35 | skipping to change at page 56, line 35 | |||
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) | ||||
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) | |||
skipping to change at page 54, line 5 | skipping to change at page 57, line 36 | |||
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. | |||
19. Open Issues | Early implementation efforts lead to good feedback by two open source | |||
implementation groups. We would like to thank the implementers for | ||||
their work and for helping us to improve the quality of the | ||||
specification: | ||||
Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ | o Wonsang Song | |||
o Jong-Yul Kim | ||||
o Anna Makarowska | ||||
o Krzysztof Rzecki | ||||
o Blaszczyk Piotr | ||||
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 2434, | |||
skipping to change at page 55, line 31 | skipping to change at page 58, line 31 | |||
[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. | |||
[6] Peterson, J., "A Presence-based GEOPRIV Location Object | [6] Peterson, J., "A Presence-based GEOPRIV Location Object | |||
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] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and | [8] Daigle, L., "Domain-Based Application Service Location Using | |||
Registration Procedures for New URI Schemes", BCP 115, | URIs and the Dynamic Delegation Discovery Service (DDDS)", | |||
RFC 4395, February 2006. | RFC 4848, April 2007. | |||
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", | [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", | |||
draft-ietf-ecrit-service-urn-05 (work in progress), | draft-ietf-ecrit-service-urn-06 (work in progress), March 2007. | |||
August 2006. | ||||
[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-05 (work in | for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in | |||
progress), February 2007. | progress), February 2007. | |||
[11] Daigle, L., "Domain-based Application Service Location Using | [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, | |||
URIs and the Dynamic Delegation Discovery Service (DDDS)", | ||||
draft-daigle-unaptr-02 (work in progress), February 2007. | ||||
[12] 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. | |||
[13] 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] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, | ||||
Considerations and Recommendations", | ||||
draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), | ||||
July 2007. | ||||
[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., "Security Threats and Requirements for Emergency | |||
Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 | Call Marking and Mapping", draft-ietf-ecrit-security-threats-04 | |||
(work in progress), July 2006. | (work in progress), April 2007. | |||
[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-12 (work in progress), | draft-ietf-ecrit-requirements-13 (work in progress), | |||
August 2006. | 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-01 (work in | Framework", draft-ietf-ecrit-mapping-arch-02 (work in | |||
progress), December 2006. | progress), July 2007. | |||
[20] Rosen, B. and J. Polk, "Best Current Practice for | [20] 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-00 (work in progress), October 2006. | draft-ietf-ecrit-phonebcp-01 (work in progress), March 2007. | |||
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 Protocol (LoST) | |||
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 cooresponding 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" /> | |||
skipping to change at page 60, line 36 | skipping to change at page 63, line 40 | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Location Information | Location Information | |||
</a:documentation> | </a:documentation> | |||
<define name="locationInformation"> | <define name="locationInformation"> | |||
<oneOrMore> | <oneOrMore> | |||
<ref name="extensionPoint"/> | <ref name="extensionPoint"/> | |||
</oneOrMore> | </oneOrMore> | |||
<optional> | ||||
<attribute name="profile"> | <attribute name="profile"> | |||
<data type="NMTOKEN" /> | <data type="NMTOKEN" /> | |||
</attribute> | </attribute> | |||
</optional> | ||||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Service Boundary | Service Boundary | |||
</a:documentation> | </a:documentation> | |||
<define name="serviceBoundary"> | <define name="serviceBoundary"> | |||
<oneOrMore> | <oneOrMore> | |||
<element name="serviceBoundary"> | <element name="serviceBoundary"> | |||
<ref name="locationInformation" /> | <ref name="locationInformation" /> | |||
</element> | </element> | |||
</oneOrMore> | </oneOrMore> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
skipping to change at page 64, line 16 | skipping to change at page 67, line 21 | |||
<ref name="extensionPoint"/> | <ref name="extensionPoint"/> | |||
</element> | </element> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Errors and Warnings Container. | Errors and Warnings Container. | |||
</a:documentation> | </a:documentation> | |||
<define name="errorContainer"> | <define name="exceptionContainer"> | |||
<interleave> | <interleave> | |||
<optional> | <optional> | |||
<ref name="badRequest" /> | <ref name="badRequest" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="internalError" /> | <ref name="internalError" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="serviceSubstitution" /> | <ref name="serviceSubstitution" /> | |||
</optional> | </optional> | |||
skipping to change at page 64, line 46 | skipping to change at page 67, line 51 | |||
<optional> | <optional> | |||
<ref name="serviceNotImplemented" /> | <ref name="serviceNotImplemented" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="serverTimeout" /> | <ref name="serverTimeout" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="serverError" /> | <ref name="serverError" /> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<ref name="locationInvalid" /> | ||||
</optional> | ||||
<optional> | ||||
<ref name="locationProfileUnrecognized" /> | <ref name="locationProfileUnrecognized" /> | |||
</optional> | </optional> | |||
</interleave> | </interleave> | |||
<ref name="extensionPoint" /> | <ref name="extensionPoint" /> | |||
<ref name="source" /> | <ref name="source" /> | |||
</define> | </define> | |||
<define name="errors"> | <define name="errors"> | |||
<element name="errors"> | <element name="errors"> | |||
<ref name="errorContainer" /> | <ref name="exceptionContainer" /> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="warnings"> | <define name="warnings"> | |||
<element name="warnings"> | <element name="warnings"> | |||
<ref name="errorContainer" /> | <ref name="exceptionContainer" /> | |||
</element> | </element> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Basic Errors | Basic Exceptions | |||
</a:documentation> | </a:documentation> | |||
<define name="basicError"> | <define name="basicException"> | |||
<a:documentation> | <a:documentation> | |||
Error pattern. | Exception pattern. | |||
</a:documentation> | </a:documentation> | |||
<ref name="message"/> | <ref name="message"/> | |||
<ref name="extensionPoint" /> | <ref name="extensionPoint" /> | |||
</define> | </define> | |||
<define name="badRequest"> | <define name="badRequest"> | |||
<element name="badRequest"> | <element name="badRequest"> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="internalError"> | <define name="internalError"> | |||
<element name="internalError"> | <element name="internalError"> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="serviceSubstitution"> | <define name="serviceSubstitution"> | |||
<element name="serviceSubstitution"> | <element name="serviceSubstitution"> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="forbidden"> | <define name="forbidden"> | |||
<element name="forbidden"> | <element name="forbidden"> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="notFound"> | <define name="notFound"> | |||
<element name="notFound"> | <element name="notFound"> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="loop"> | <define name="loop"> | |||
<element name="loop"> | <element name="loop"> | |||
<ref name="basicError" /> | <ref name="basicException" /> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="serviceNotImplemented"> | <define name="serviceNotImplemented"> | |||
<element name="serviceNotImplemented"> | <element name="serviceNotImplemented"> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="serverTimeout"> | <define name="serverTimeout"> | |||
<element name="serverTimeout"> | <element name="serverTimeout"> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="serverError"> | <define name="serverError"> | |||
<element name="serverError"> | <element name="serverError"> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | ||||
</define> | ||||
<define name="locationInvalid"> | ||||
<element name="locationInvalid"> | ||||
<ref name="basicException"/> | ||||
</element> | ||||
</define> | ||||
<define name="locationValidationUnavailable"> | ||||
<element name="locationValidationUnavailable"> | ||||
<ref name="basicException" /> | ||||
</element> | </element> | |||
</define> | </define> | |||
<define name="locationProfileUnrecognized"> | <define name="locationProfileUnrecognized"> | |||
<element name="locationProfileUnrecognized"> | <element name="locationProfileUnrecognized"> | |||
<attribute name="unsupportedProfiles"> | <attribute name="unsupportedProfiles"> | |||
<data type="NMTOKENS" /> | <data type="NMTOKENS" /> | |||
</attribute> | </attribute> | |||
<ref name="basicError"/> | <ref name="basicException"/> | |||
</element> | </element> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Redirect. | Redirect. | |||
</a:documentation> | </a:documentation> | |||
<define name="redirect"> | <define name="redirect"> | |||
<a:documentation> | <a:documentation> | |||
Redirect pattern | Redirect pattern | |||
</a:documentation> | </a:documentation> | |||
<element name="redirect"> | <element name="redirect"> | |||
<attribute name="target"> | <attribute name="target"> | |||
<ref name="appUniqueString" /> | <ref name="appUniqueString" /> | |||
</attribute> | </attribute> | |||
<ref name="source" /> | <ref name="source" /> | |||
<ref name="message" /> | <ref name="message" /> | |||
skipping to change at page 69, line 29 | skipping to change at page 73, line 4 | |||
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 25 | ||||
Figure 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 | |||
SunRocket | TranTech, Inc. | |||
8045 Leesburg Pike, Suite 300 | 4900 Seminary Road, Suite 215 | |||
Vienna, VA 22182 | Alexandria, VA 22311 | |||
US | US | |||
Phone: +1 703 636 0852 | Phone: +1 703 671 9873 | |||
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 | |||
Siemens Networks GmbH & Co KG | Nokia Siemens Networks | |||
Otto-Hahn-Ring 6 | Otto-Hahn-Ring 6 | |||
Munich, Bavaria 81739 | Munich, Bavaria 81739 | |||
Germany | Germany | |||
Phone: +49 89 636 40390 | Phone: +49 89 636 40390 | |||
Email: Hannes.Tschofenig@siemens.com | Email: Hannes.Tschofenig@nsn.com | |||
URI: http://www.tschofenig.com | URI: http://www.tschofenig.com | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
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. 227 change blocks. | ||||
450 lines changed or deleted | 633 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/ |