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