draft-ietf-ecrit-lost-01.txt | draft-ietf-ecrit-lost-02.txt | |||
---|---|---|---|---|
Network Working Group T. Hardie | Network Working Group T. Hardie | |||
Internet-Draft Qualcomm, Inc. | Internet-Draft Qualcomm, Inc. | |||
Intended status: Standards Track A. Newton | Intended status: Standards Track A. Newton | |||
Expires: March 8, 2007 SunRocket | Expires: April 25, 2007 SunRocket | |||
H. Schulzrinne | H. Schulzrinne | |||
Columbia U. | Columbia U. | |||
H. Tschofenig | H. Tschofenig | |||
Siemens | Siemens | |||
September 4, 2006 | October 22, 2006 | |||
LoST: A Location-to-Service Translation Protocol | LoST: A Location-to-Service Translation Protocol | |||
draft-ietf-ecrit-lost-01.txt | draft-ietf-ecrit-lost-02.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on March 8, 2007. | This Internet-Draft will expire on April 25, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
This document describes an XML-based protocol for mapping service | This document describes an XML-based protocol for mapping service | |||
identifiers and geospatial or civic location information to service | identifiers and geodetic or civic location information to service | |||
contact URIs. In particular, it can be used to determine the | contact URIs. In particular, it can be used to determine the | |||
location-appropriate PSAP for emergency services. | location-appropriate PSAP for emergency services. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 | 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 | |||
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4. Resolving Service URNs Using LoST . . . . . . . . . . . . . . 8 | 4. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 8 | |||
5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 5. LoST Uniform Resource Locators and Their Resolution . . . . . 9 | |||
5.1. Location Information Element . . . . . . . . . . . . . . . 9 | 6. Mapping a Location and Service to URLs: <findService> . . . . 10 | |||
5.2. Service Element . . . . . . . . . . . . . . . . . . . . . 9 | 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.3. Validate Attribute . . . . . . . . . . . . . . . . . . . . 9 | 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.4. Query Message Examples . . . . . . . . . . . . . . . . . . 9 | 6.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 10 | |||
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 6.2.2. Civic Address Mapping Example . . . . . . . . . . . . 11 | |||
6.1. Uniform Resource Identifiers (URI) Element . . . . . . . . 11 | 6.3. Components of <findService> Request . . . . . . . . . . . 13 | |||
6.2. Display Name Element . . . . . . . . . . . . . . . . . . . 11 | 6.3.1. The <location> Element . . . . . . . . . . . . . . . . 13 | |||
6.3. Service Element . . . . . . . . . . . . . . . . . . . . . 11 | 6.3.2. The <service> Element . . . . . . . . . . . . . . . . 13 | |||
6.4. ServiceBoundary Element . . . . . . . . . . . . . . . . . 12 | 6.3.3. Recursion or Redirection . . . . . . . . . . . . . . . 13 | |||
6.5. ServiceNumber Element . . . . . . . . . . . . . . . . . . 12 | 6.3.4. Configuring the Response . . . . . . . . . . . . . . . 14 | |||
6.6. TimeToLive Attribute . . . . . . . . . . . . . . . . . . . 12 | 6.4. Components of the Mapping Response | |||
6.7. Validation Element . . . . . . . . . . . . . . . . . . . . 12 | <findServiceResponse> . . . . . . . . . . . . . . . . . . 16 | |||
6.8. Response Message Examples . . . . . . . . . . . . . . . . 12 | 6.4.1. Source of Response: <via> Element . . . . . . . . . . 16 | |||
7. List Services Query and Response . . . . . . . . . . . . . . . 15 | 6.4.2. Service URLs: the <uri> Element . . . . . . . . . . . 16 | |||
7.1. List Service Query . . . . . . . . . . . . . . . . . . . . 15 | 6.4.3. Describing the Service with the <displayName> | |||
7.2. List Service Response . . . . . . . . . . . . . . . . . . 15 | Element . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17 | 6.4.4. Approximating Services: the <service> Element . . . . 17 | |||
8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17 | 6.4.5. Defining the Service Region with the | |||
8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 17 | <serviceBoundary> Element . . . . . . . . . . . . . . 17 | |||
8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 17 | 6.4.6. Service Boundaries by Reference: the | |||
8.2.2. 201 Service Substitution . . . . . . . . . . . . . . . 17 | <serviceBoundaryReference> Element . . . . . . . . . . 17 | |||
8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 17 | 6.4.7. The Service Number . . . . . . . . . . . . . . . . . . 18 | |||
8.3.1. 301 Move Permanently . . . . . . . . . . . . . . . . . 17 | 6.4.8. Civic Address Validation . . . . . . . . . . . . . . . 18 | |||
8.3.2. 302 Moved Temporarily . . . . . . . . . . . . . . . . 18 | 6.4.9. Validity: The 'timeToLive' Attribute . . . . . . . . . 18 | |||
8.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18 | 7. Retrieving the Service Boundary via <getServiceBoundary> . . . 19 | |||
8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 18 | 8. List Services: <listServices> . . . . . . . . . . . . . . . . 21 | |||
8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 18 | 9. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 23 | |||
8.4.2. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 18 | 9.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 23 | |||
8.4.3. 404 Not Found . . . . . . . . . . . . . . . . . . . . 18 | 9.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 26 | |||
8.4.4. 414 Location Error . . . . . . . . . . . . . . . . . . 18 | 9.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 26 | |||
8.4.5. Example . . . . . . . . . . . . . . . . . . . . . . . 18 | 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 20 | 10.1. Basic Errors . . . . . . . . . . . . . . . . . . . . . . . 27 | |||
8.5.1. 500 Server Internal Error . . . . . . . . . . . . . . 20 | 10.2. Response Errors . . . . . . . . . . . . . . . . . . . . . 27 | |||
8.5.2. 501 Service Not Implemented . . . . . . . . . . . . . 20 | 10.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
8.5.3. 504 Server Time-Out . . . . . . . . . . . . . . . . . 21 | 11. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
8.5.4. Example . . . . . . . . . . . . . . . . . . . . . . . 21 | 12. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
9. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 22 | 13. Internationalization Considerations . . . . . . . . . . . . . 37 | |||
10. LoST Uniform Resource Locators . . . . . . . . . . . . . . . . 23 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | |||
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 14.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 38 | |||
12. Deployment Methods . . . . . . . . . . . . . . . . . . . . . . 26 | 14.2. Content-type registration for 'application/lost+xml' . . . 38 | |||
13. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 28 | 14.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 40 | |||
14. Internationalization Considerations . . . . . . . . . . . . . 33 | 14.4. LoST Namespace Registration . . . . . . . . . . . . . . . 40 | |||
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | 14.5. Registration Template . . . . . . . . . . . . . . . . . . 41 | |||
15.1. Content-type registration for 'application/lost+xml' . . . 34 | 14.6. LoST Location Profile Registry . . . . . . . . . . . . . . 42 | |||
15.2. LoST Relax NG Schema Registration . . . . . . . . . . . . 35 | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 43 | |||
15.3. LoST Namespace Registration . . . . . . . . . . . . . . . 36 | 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
15.4. Registration Template . . . . . . . . . . . . . . . . . . 36 | 17. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45 | |||
16. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 | |||
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 | 18.1. Normative References . . . . . . . . . . . . . . . . . . . 46 | |||
18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 40 | 18.2. Informative References . . . . . . . . . . . . . . . . . . 47 | |||
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 | Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 48 | |||
19.1. Normative References . . . . . . . . . . . . . . . . . . . 41 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
19.2. Informative References . . . . . . . . . . . . . . . . . . 42 | Intellectual Property and Copyright Statements . . . . . . . . . . 62 | |||
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 43 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 52 | ||||
1. Introduction | 1. Introduction | |||
This document describes a protocol for mapping a service identifier | This document describes a protocol for mapping a service identifier | |||
[6] and location information compatible with PIDF-LO [11] to one or | [10] and location information compatible with PIDF-LO [8] to one or | |||
more service contact URIs. Example contact URI schemes include sip, | more service contact URIs. Example contact URI schemes include sip | |||
xmpp, and tel. While the initial focus is on providing mapping | [14], xmpp [15], and tel [16]. While the initial focus is on | |||
functions for emergency services, it is likely that the protocol is | providing mapping functions for emergency services, it is likely that | |||
applicable to any service URN. For example, in the United States, | the protocol is applicable to any service URN. For example, in the | |||
the "2-1-1" and "3-1-1" services follow a similar location-to-service | United States, the "2-1-1" and "3-1-1" services follow a similar | |||
behavior as emergency services. | location-to-service behavior as emergency services. | |||
This document names this protocol usage "LoST" for Location-to- | ||||
Service Translation Protocol. The features of LoST are: | ||||
o Supports queries using civic as well as geospatial location | ||||
information. | ||||
o Support for recursive and iterative resolution. | ||||
o Support for address validation. | ||||
o A hierarchical deployment of mapping servers is independent of | ||||
civic location labels. | ||||
o Indication of errors in the location data to facilitate debugging | ||||
and proper user feedback while simultaneously providing best- | ||||
effort answers. | ||||
o Mapping can be based on either civic or geospatial location | ||||
information, with uniform protocol treatment of both. | ||||
o Support for overlapping service regions. | ||||
o Satisfies the requirements [5] for mapping protocols. | This document names this protocol "LoST", for Location-to-Service | |||
Translation. LoST Satisfies the requirements [18] for mapping | ||||
protocols. LoST provides a number of operations, centered around | ||||
mapping locations and service URNs to URIs and associated | ||||
information. LoST mapping queries can contain either civic or | ||||
geodetic location information. For civic addresses, LoST can | ||||
indicate which parts of the civic address are known to be valid or | ||||
invalid, thus providing address validation. LoST indicates errors in | ||||
the location data to facilitate debugging and proper user feedback, | ||||
but also provides best-effort answers. | ||||
o Minimizes round trips by caching individual mappings and by | LoST queries can be resolved recursively or iteratively. To minimize | |||
supporting return of coverage regions ("hinting"). | round trips, LoST caches individual mappings and indicates the region | |||
for which the same answer would be returned ("service region"). | ||||
o Facilitates reuse of Transport Layer Security (TLS). | As currently defined, LoST messages are carried in HTTP and HTTPS | |||
protocol exchanges, facilitating use of TLS for protecting the | ||||
integrity and confidentiality of requests and responses. | ||||
This document focuses on the description of the protocol between the | This document focuses on the description of the protocol between the | |||
mapping client (seeker or resolver) and the mapping server (resolver | mapping client (seeker or resolver) and the mapping server (resolver | |||
or other servers). The relationship between other functions, such as | or other servers). The relationship between 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 in general, will be described in a | mapping server architecture are described in a separate document | |||
separate document. [20] is a first attempt to describe such a mapping | [19]. | |||
server architecture. | ||||
The high-level protocol operation can be described as follows: | ||||
Location | ||||
Info +----------+ | ||||
--------> | | | ||||
Service | LoST | | ||||
URN | Server | | ||||
--------> | | | ||||
+----------+ | ||||
Query | ||||
URI +----------+ | ||||
<------- | | | ||||
Optional | LoST | | ||||
Info (hints)| Server | | ||||
<------- | | | ||||
+----------+ | ||||
Response | ||||
Figure 1: Overview | ||||
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 [6]) from | identifier encoded as a Uniform Resource Name (URN) (see [10]) 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 a Uniform Resource Identifiers | database to map the input values to one or more Uniform Resource | |||
(URI) and returns it including optional information such as hints | Identifiers (URI) and returns those URIs along with optional | |||
about the service boundary in a response message back to the LoST | information such as hints about the service boundary in a response | |||
client. | 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 | ||||
another LoST server, identified by a LoST URL (Section 5). In | ||||
addition to the mapping function described in Section 6, the protocol | ||||
also allows to retrieve the service boundary Section 7 and to list | ||||
the services available for a particular location Section 8. | ||||
2. Requirements Notation | 2. 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 [3]. | document are to be interpreted as described in [1]. | |||
3. Usage | 3. Terminology | |||
The client queries a server, indicating the desired service and | This document furthermore uses the terminology defined in [18]. | |||
location information. If the query succeeds, the server returns a | ||||
result that includes one or more URIs for reaching the appropriate | In examples, the XML sent by the client is prepended with "C:" and | |||
service for the location indicated. Depending on the query, the | the XML sent by the server is prepended with "S:". | |||
result may contain a service boundary where the same mapping would | ||||
apply, a reference to another server to which the client should send | 4. Overview of Protocol Usage | |||
a query, or an error messages indicating problems. The combination | ||||
of these components are left to the needs and policy of the | ||||
jurisdiction where the server is being operated. | ||||
The client may perform the mapping at any time. Among the common | The client may perform the mapping at any time. Among the common | |||
triggers for mapping are: | triggers for mapping requests are: | |||
1. When the client starts up and/or attaches to a new network | 1. When the client initially starts up or attaches to a network. | |||
location. | ||||
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 region returned | sufficiently that it is outside the bounds of the service region | |||
in an earlier query. | returned in an earlier LoST query. | |||
3. When cached mapping information has expired. | 3. When cached mapping information has expired. | |||
4. When calling for a particular service. During such calls, a | 4. When invoking a particular service. At that time, a client may | |||
client may want to request a short response that contains only | omit requests for service boundaries or other auxiliary | |||
the mapping data, omitting service boundary information. | information. | |||
Cached answers are expected to be used by clients only after failing | A service-specific BCP such as [20] governs whether a client is | |||
to accomplish a location-to-URI mapping at call time. Cache entries | expected to invoke the mapping service just before needing the | |||
may expire according to their time-to-live value, or they may become | service or whether to rely on cached answers. Cache entries expire | |||
invalid if the location of the caller's device moves outside the | according to their time-to-live value (see Section 6.4.9, or they | |||
boundary limits of the cache entry. Boundaries for cache entries may | become invalid if the caller's device moves beyond the boundaries of | |||
be set in both geospatial and civic terms. | the service region. | |||
4. Resolving Service URNs Using LoST | 5. LoST Uniform Resource Locators and Their Resolution | |||
LoST servers are identified by LoST Uniform Resource Locators (URLs), | ||||
which follow the format of URLs defined in RFC 3986 [7], with the | ||||
following ABNF: | ||||
LoST-URI = "lost:" host | ||||
'host' is defined in Section 3.2.2 of RFC 3986 [7]. | ||||
An example is 'lost:lostserver.example.com' | ||||
If a LoST URL contains a host name rather than an IP address, clients | If a LoST URL contains a host name rather than an IP address, clients | |||
need to perform an U-NAPTR [17] lookup to obtain a DNS A record and | need to use U-NAPTR [12] using the U-NAPTR specification described | |||
IP address. These records map the 'host' part of the LoST URL to one | below to obtain a URI (indicating host and protocol) for the | |||
or more URLs indicating the protocol to carry the LoST request. In | applicable LoST service. In this document, only the HTTP and HTTPS | |||
this document, only the HTTP and HTTPS URL schemes are defined. Note | URL schemes are defined. Note that the HTTP URL can be any valid | |||
that the HTTP URL can be any valid HTTP URL, including those | HTTP URL, including those containing path elements. | |||
containing path elements. | ||||
Here is an example: | The following two DNS entries resolve the LoST URL "lost:example.com" | |||
to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL | ||||
http://lostserver.example.com, with the former being preferred. | ||||
example.com. | 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!" "" | |||
5. Query | 6. Mapping a Location and Service to URLs: <findService> | |||
LoST provides the ability to use civic or geospatial location | ||||
information in the query message. In addition to location | ||||
information the query also contains a service identifier. An | ||||
optional parameter might furthermore request the LoST server to | ||||
validate location information. | ||||
5.1. Location Information Element | ||||
LoST supports a query using geospatial and civic location information | ||||
using the <findServiceByLocation> query. Geospatial location | ||||
information uses GML format [10] and civic location information | ||||
utilizes the format defined in [16]. This document does not define | ||||
location formats. | ||||
5.2. Service Element | ||||
The type of service desired is specified by the <service> element. | ||||
The (emergency) service identifiers listed in the registry | ||||
established with [6] will be used in this document. | ||||
The <service> element is a mandatory element. In case the database | ||||
at the LoST server does not provided service for the specific | ||||
geographical region the LoST server has various choices with regard | ||||
to the response: | ||||
o It can send an error response. | 6.1. Overview | |||
o It can map one service to another one, if appropriate, and return | The <findService> query constitutes the core of the LoST | |||
a different service identifier as described in Section 6.3. | functionality, mapping civic or geodetic locations to URLs and | |||
associated data. After giving an example, we enumerate the elements | ||||
of the query and response. | ||||
o It can populate the URIs of one service to another service. | 6.2. Examples | |||
The operation of the LoST server is largely a policy issue. No | 6.2.1. Example Using Geodetic Coordinates | |||
behavior is mandated in this document. Guidelines for operating a | ||||
LoST server for emergency services is provided in [21]. | ||||
5.3. Validate Attribute | The following is an example of mapping a service to a location using | |||
geodetic coordinates, for the service associated with the police | ||||
(urn:service:sos.police). | ||||
The 'validate' attribute implements the validation behavior described | <?xml version="1.0" encoding="UTF-8"?> | |||
in [5]. | <findService xmlns="urn:ietf:params:xml:ns:lost1" | |||
xmlns:p2="http://www.opengis.net/gml" recursive="true" | ||||
include="uri service serviceNumber displayName serviceBoundary"> | ||||
<location | ||||
profile="urn:ietf:params:lost:location-profile:geodetic-2d"> | ||||
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> | ||||
<p2:pos>40.8089897 -73.9612492</p2:pos> | ||||
</p2:Point> | ||||
</location> | ||||
<service>urn:service:sos.police</service> | ||||
</findService> | ||||
5.4. Query Message Examples | Figure 2: A <findService> Geodetic Query | |||
This section shows an example of a query message providing geospatial | Given the query above, a server would respond with a service, and | |||
and civic location information. | information related to that service. In the example below, the | |||
server has mapped the location given by the client for a police | ||||
service to the New York City Police Deparment, instructing the client | ||||
that it may contact them via the URIs sip:nypd@example.com and | ||||
xmpp:nypd@example.com. The server has also given the client a | ||||
geodetic, two-dimensional boundary for this service and time-to-live | ||||
value of 3,600 seconds. This instructs the client that if its | ||||
location changes beyond the give service boundary or if 3,600 seconds | ||||
has elapsed, it would need to requery for this information. | ||||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<findServiceByLocation | <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" | |||
xmlns="urn:ietf:params:xml:ns:lost1" | xmlns:p2="http://www.opengis.net/gml" timeToLive="3600"> | |||
xmlns:p2="http://www.opengis.net/gml" | <displayName xml:lang="en"> | |||
validate="false" operation="recursive"> | New York City Police Department | |||
<locationInfo> | </displayName> | |||
<p2:Point id="point1" srsName="epsg:4326"> | ||||
<p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> | ||||
</p2:Point> | ||||
</locationInfo> | ||||
<service>urn:service:sos.police</service> | <service>urn:service:sos.police</service> | |||
</findServiceByLocation> | <serviceBoundary | |||
profile="urn:ietf:params:lost:location-profile:geodetic-2d"> | ||||
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | ||||
<p2:exterior> | ||||
<p2:LinearRing> | ||||
<p2:pos>37.775 -122.4194</p2:pos> | ||||
<p2:pos>37.555 -122.4194</p2:pos> | ||||
<p2:pos>37.555 -122.4264</p2:pos> | ||||
<p2:pos>37.775 -122.4264</p2:pos> | ||||
<p2:pos>37.775 -122.4194</p2:pos> | ||||
</p2:LinearRing> | ||||
</p2:exterior> | ||||
</p2:Polygon> | ||||
</serviceBoundary> | ||||
<uri>sip:nypd@example.com</uri> | ||||
<uri>xmpp:nypd@example.com</uri> | ||||
<serviceNumber>911</serviceNumber> | ||||
</findServiceResponse> | ||||
Figure 3: Query Message Example using Geospatial Location Information | Figure 3: A <findServiceResponse> Geodetic Answer | |||
The example above shows a query using geospatial location information | 6.2.2. Civic Address Mapping Example | |||
with no validation required and asking for the | ||||
'urn:service:sos.police' service. | The following is an example of mapping a service to a location much | |||
like the example in Section 6.2.1, but using civic address location | ||||
information. In this example, the client requests the service | ||||
associated with police (urn:service:sos.police) along with a specific | ||||
civic address (house number 96 on a street named Neu Perlach in | ||||
Munich, Germany). | ||||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1" | <findService xmlns="urn:ietf:params:xml:ns:lost1" | |||
validate="false" operation="recursive"> | recursive="true" | |||
<locationInfo> | include="uri serviceNumber displayName serviceBoundary" > | |||
<civicLocation> | <location | |||
profile="urn:ietf:params:lost:location-profile:basic-civic"> | ||||
<civicAddress | ||||
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> | ||||
<country>Germany</country> | <country>Germany</country> | |||
<A1>Bavaria</A1> | <A1>Bavaria</A1> | |||
<A3>Munich</A3> | <A3>Munich</A3> | |||
<A6>Neu Perlach</A6> | <A6>Neu Perlach</A6> | |||
<HNO>96</HNO> | <HNO>96</HNO> | |||
<PC>81675</PC> | <PC>81675</PC> | |||
</civicLocation> | </civicAddress> | |||
</locationInfo> | </location> | |||
<service>urn:service:sos.police</service> | <service>urn:service:sos.police</service> | |||
</findServiceByLocation> | </findService> | |||
Figure 4: Query Message Example using Civic Location Information | ||||
The example above shows a query using a civic location in Munich | ||||
asking for the 'urn:service:sos.police' service. The query indicates | ||||
that validation is not desired and the query has to be executed | ||||
recursively. | ||||
6. Response | ||||
A response message might either contain civic or geospatial location | ||||
information depending on the type of the query. If the | ||||
findServiceByLocation query message contained civic location | ||||
information then the <serviceBoundary> element of the response | ||||
message will also contain civic information. If the | ||||
findServiceByLocation query message contained geospatial location | ||||
information then the <serviceBoundary> element of the response | ||||
message will contain a GML polygon. More information about the | ||||
<serviceBoundary> element can be found at Section 6.4. | ||||
6.1. Uniform Resource Identifiers (URI) Element | ||||
Each <uri> element contains an appropriate contact URI for the | ||||
service for which mapping was requested. <uri> elements are of type | ||||
xs:anyURI. In the emergency service context operators are strongly | ||||
discouraged from using relative URIs, even though these are permitted | ||||
by the type. | ||||
6.2. Display Name Element | Figure 4: A <findService> Civic Address Query | |||
Each <displayName> element contains a string that is suitable for | Given the query above, a server would respond with a service, and | |||
display. <displayName> elements are of type "text" that is suitable | information related to that service. In the example below, the | |||
for internationalized human-readable text. | server has mapped the location given by the client for a police | |||
service to the Mȭnchen Polizei-Abteilung, instructing the client | ||||
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 | ||||
client a civic address boundary (the city of Munich) for this service | ||||
and time-to-live value of 3,600 seconds. This instructs the client | ||||
that if its location changes beyond the give service boundary (i.e. | ||||
beyond the city of Munich) or if 3,600 seconds has elapsed, it would | ||||
need to requery for this information. | ||||
6.3. Service Element | <?xml version="1.0" encoding="UTF-8"?> | |||
<findServiceResponse | ||||
xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600"> | ||||
<displayName xml:lang="de"> | ||||
Mȭnchen Polizei-Abteilung | ||||
</displayName> | ||||
<service>urn:service:sos.police</service> | ||||
<serviceBoundary | ||||
profile="urn:ietf:params:lost:location-profile:basic-civic"> | ||||
<civicAddress | ||||
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> | ||||
<country>Germany</country> | ||||
<A1>Bavaria</A1> | ||||
<A3>Munich</A3> | ||||
<PC>81675</PC> | ||||
</civicAddress> | ||||
</serviceBoundary> | ||||
<uri>sip:munich-police@example.com</uri> | ||||
<uri>xmpp:munich-police@example.com</uri> | ||||
<serviceNumber>110</serviceNumber> | ||||
</findServiceResponse> | ||||
The <service> element is an optional element in the response message. | Figure 5: A <findServiceResponse> Civic Address Answer | |||
The (emergency) service identifiers listed in the registry | ||||
established with [6] will be used in this document. If the service | ||||
that was requested by the LoST client is not available for a | ||||
particular location then the server MAY return an alternate service. | ||||
If it does so, it MUST indicate the actual service returned (i.e., | ||||
its service URN). Alternatively, the LoST server MAY return an error | ||||
response indicating that the requested service is not available. | ||||
The following example illustrates the main idea. If there is a | 6.3. Components of <findService> Request | |||
region that only understands the 'urn:service:sos' service and not | ||||
'urn:service:sos.fire', 'urn:service:sos.ambulance', and | ||||
'urn:service:sos.police'. If a LoST client asks for the | ||||
'urn:service:sos.fire' service then the LoST server could, depending | ||||
on the local policy at the LoST server, return: | ||||
1. 'urn:service:sos', or | 6.3.1. The <location> Element | |||
2. 'urn:service:sos.fire' with the values of 'urn:service:sos' being | The <findService> query communicates location using one or more | |||
populated to 'urn:service:sos.fire', or | <location> elements, which MUST conform to a location profile | |||
3. an error message | (Section 9). | |||
In case of (1) the <service> element carries the value of | 6.3.2. The <service> Element | |||
'urn:service:sos'. | ||||
6.4. ServiceBoundary Element | The type of service desired is specified by the <service> element. | |||
It contains service URNs from the registry established in [10]. | ||||
Each <serviceBoundary> element contains either one or more civic | 6.3.3. Recursion or Redirection | |||
location elements derived from the GeoPriv civic address schema or a | ||||
GML-based polygon. | ||||
The <serviceBoundary> element indicates where the same query would | LoST <findService> queries can be recursive or iterative, as | |||
yield to the same response, i.e., it provides information about the | indicated by the 'recursive' attribute. A value of "true" indicates | |||
service boundary. | a recursive query, a value of "false" an iterative query, with | |||
iterative being the default. When the LoST server cannot answer the | ||||
query and the query requested iterative resolution, it will return an | ||||
<iterativeSearchExhausted> (Section 10.3) error message with the LoST | ||||
URI pointing to a different LoST server that the LoST client should | ||||
contact. In recursive mode, the LoST server initiates a query and | ||||
returns the result to the original querier, inserting a <via> element | ||||
to track the response chain. | ||||
6.5. ServiceNumber Element | 6.3.4. Configuring the Response | |||
TBD: This element contains the (emergency) service number, which is a | The 'include' attribute enumerates all the XML elements that the | |||
string of digits used to reach the (emergency) service. | client wants the LoST server to provide in the mapping response. The | |||
server ignores any element names that it does not understand. The | ||||
ordering of the tokens is immaterial. | ||||
6.6. TimeToLive Attribute | Among other features, it determines whether service boundaries are | |||
returned and whether they are returned by value or reference | ||||
Section 7, and whether to validate civic locations. | ||||
Each timeToLive attribute is a positive integer, expressing the | Address validation is requested by including the XML element names | |||
validity period of the response in seconds. The LoST client MUST NOT | that provide address validation in the 'include' attribute, namely | |||
consider the returned location current after the expiration of the | 'valid', 'invalid' and 'unchecked'. The following example | |||
validity period. | demonstrates address validation. | |||
6.7. Validation Element | C: <?xml version="1.0" encoding="UTF-8"?> | |||
C: <findService | ||||
C: xmlns="urn:ietf:params:xml:ns:lost1" | ||||
C: recursive="true" | ||||
C: include="uri serviceNumber invalid valid unchecked"> | ||||
C: <location | ||||
C: profile="urn:ietf:params:lost:location-profile:basic-civic"> | ||||
C: <civicAddress | ||||
C: xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> | ||||
C: <country>Germany</country> | ||||
C: <A1>Bavaria</A1> | ||||
C: <A3>Munich</A3> | ||||
C: <A6>Neu Perlach</A6> | ||||
C: <HNO>96</HNO> | ||||
C: <PC>81675</PC> | ||||
C: </civicAddress> | ||||
C: </location> | ||||
C: <service>urn:service:sos.police</service> | ||||
C: </findService> | ||||
The <validation> element contains a string that is composed of | S: <?xml version="1.0" encoding="UTF-8"?> | |||
concatenated tokens separated by a whitespace. These tokens refer to | S: <findServiceResponse | |||
the civic location labels used in child elements of the | S: xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600"> | |||
<civicAddress> element from the request that have been recognized as | S: <displayName xml:lang="de"> | |||
valid by the server. | S: Mȭnchen Polizei-Abteilung | |||
S: </displayName> | ||||
S: <service>urn:service:sos.police</service> | ||||
S: <serviceBoundary | ||||
S: profile="urn:ietf:params:lost:location-profile:basic-civic"> | ||||
S: <civicAddress | ||||
S: xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> | ||||
S: <country>Germany</country> | ||||
S: <A1>Bavaria</A1> | ||||
S: <A3>Munich</A3> | ||||
S: <PC>81675</PC> | ||||
S: </civicAddress> | ||||
S: </serviceBoundary> | ||||
S: <uri>sip:munich-police@example.com</uri> | ||||
S: <uri>xmpp:munich-police@example.com</uri> | ||||
S: <serviceNumber>110</serviceNumber> | ||||
S: <valid>country A1 A3 A6</valid> | ||||
S: <invalid>PC</invalid> | ||||
S: </findServiceResponse> | ||||
The following code snippet indicates that the civic address labels | Figure 6: Address Validation Exchange | |||
'country', 'A1', 'A3', 'A6, 'PC' have been valided by the LoST | ||||
server. | ||||
<validation>country A1 A3 A6 PC</validation> | 6.4. Components of the Mapping Response <findServiceResponse> | |||
6.8. Response Message Examples | 6.4.1. Source of Response: <via> Element | |||
This section shows an example of a query message providing geospatial | A <findServiceResponse> indicates the source of the response by | |||
and civic location information. | including a <via> element with a LoST URL as the first <via> element. | |||
Thus, each server "initials" its own response. Thus, responses to | ||||
iterative queries contain one <via> element, while responses to | ||||
recursive queries may reach the original querier with multiple <via> | ||||
elements, one for each server that was used in the resolution. The | ||||
following <findServiceResponse> example illustrates the use of <via>: | ||||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<response | <findServiceResponse | |||
xmlns="urn:ietf:params:xml:ns:lost1" | xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600"> | |||
xmlns:p2="http://www.opengis.net/gml" > | <via>lost:esgw.uber-110.de.example</via> | |||
<result status="200" message="OK" xml:lang="en" timeToLive="1000"> | <via>lost:polizei.munchen.de.example</via> | |||
<displayName xml:lang="en"> | <displayName xml:lang="de"> | |||
New York City Police Department | Mȭnchen Polizei-Abteilung | |||
</displayName> | </displayName> | |||
<service>urn:service:sos.police</service> | <service>urn:service:sos.police</service> | |||
<serviceBoundary> | <serviceBoundary | |||
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | profile="urn:ietf:params:lost:location-profile:basic-civic"> | |||
<p2:exterior> | <civicAddress | |||
<p2:LinearRing> | xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> | |||
<p2:pos>37.775 -122.4194</p2:pos> | ||||
<p2:pos>37.555 -122.4194</p2:pos> | ||||
<p2:pos>37.555 -122.4264</p2:pos> | ||||
<p2:pos>37.775 -122.4264</p2:pos> | ||||
<p2:pos>37.775 -122.4194</p2:pos> | ||||
</p2:LinearRing> | ||||
</p2:exterior> | ||||
</p2:Polygon> | ||||
</serviceBoundary> | ||||
<uri>sip:nypd@example.com</uri> | ||||
<uri>xmpp:nypd@example.com</uri> | ||||
<serviceNumber>911</serviceNumber> | ||||
</result> | ||||
</response> | ||||
Figure 6: Response Message Example using Geospatial Location Service | ||||
Boundary Hints | ||||
This example shows a response with two URIs for the previously | ||||
queried service URN. Information about the service boundary is | ||||
provided by a GML polygon. The <serviceNumber> element indicates the | ||||
valid service number for the expressed location and service URN. | ||||
<?xml version="1.0" encoding="UTF-8"?> | ||||
<response xmlns="urn:ietf:params:xml:ns:lost1"> | ||||
<result status="200" timeToLive="10000"> | ||||
<displayName xml:lang="de">Munich Police Department</displayName> | ||||
<service>urn:service:sos.police</service> | ||||
<serviceBoundary> | ||||
<civicLocation> | ||||
<country>Germany</country> | <country>Germany</country> | |||
<A1>Bavaria</A1> | <A1>Bavaria</A1> | |||
<A3>Munich</A3> | <A3>Munich</A3> | |||
<PC>81675</PC> | <PC>81675</PC> | |||
</civicLocation> | </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> | |||
<service-number>110</service-number> | <serviceNumber>110</serviceNumber> | |||
</result> | </findServiceResponse> | |||
</response> | ||||
Figure 7: Response Message Example providing Civic Location Service | Figure 7: An Example of a Response Using <via> | |||
Boundary Hints | ||||
This example shows a response that returns two URIs (one for SIP and | The example above indicates that the this answer was given to the | |||
another one for XMPP), a distring that indicates the valid distring | responding server by the LoST server at esgw.uber-110.de.example, | |||
for the location provided in the query, a hint about the service | which got the answer from the LoST server at | |||
boundary in the <serviceBoundary> element and information about the | polizei.munchen.de.example. | |||
validated civic address fields. The timeToLive attribute indicates | ||||
that the returned information can be cached for 10000 seconds and | ||||
provides a *<displayName> element with additional, textual | ||||
information about the returned information. | ||||
7. List Services Query and Response | 6.4.2. Service URLs: the <uri> Element | |||
7.1. List Service Query | The response returns the service URLs in one or more <uri> elements. | |||
The URLs MUST be absolute URLs. | ||||
This subsection describes a mechanism that offers the LoST client to | 6.4.3. Describing the Service with the <displayName> Element | |||
query for available service identifiers supported by the LoST server. | ||||
The listServices query MUST carry the <locationInfo> and the | ||||
<service> element. The LoST server MUST return only immediate child | ||||
elements of the service identifier specified in the <service> element | ||||
of the listServices query available for the provided location | ||||
information. | ||||
<?xml version="1.0" encoding="UTF-8"?> | The <displayName> element describes the service with a string that is | |||
<listServices | suitable for display to human users, annotated with the 'xml:lang' | |||
xmlns="urn:ietf:params:xml:ns:lost1" | attribute that contains a language tag to aid in the rendering of | |||
xmlns:p2="http://www.opengis.net/gml" | text. | |||
operation="false"> | ||||
<locationInfo> | 6.4.4. Approximating Services: the <service> Element | |||
<p2:Point id="point1" srsName="epsg:4326"> | ||||
<p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> | ||||
</p2:Point> | ||||
</locationInfo> | ||||
<service>urn:service:sos</service> | ||||
</listServices> | ||||
Figure 8: Example for a List Service Query | If the requested service, identified by the service URN [10] in the | |||
<service> element in the request, does not exist for the location | ||||
indicated, the server can either return an <serviceNotImplemented> | ||||
(Section 10.2) error or can provide an alternate service that | ||||
approximates the desired service for that location. In the latter | ||||
case, the server MUST include a <service> element with the | ||||
alternative service URN. The choice of service URN is left to local | ||||
policy, but the alternate service should be able to satisfy the | ||||
original service request. | ||||
This listService query aims to query the immediate child elements of | 6.4.5. Defining the Service Region with the <serviceBoundary> Element | |||
the 'urn:service:sos' URN. | ||||
7.2. List Service Response | A response can indicate the region for which the service URL returned | |||
would be the same as in the actual query, the so-called service | ||||
region. The service region can be indicated by value or by reference | ||||
Section 6.4.6. If a client moves outside the service area, it MUST | ||||
send a new query with its current location to obtain valid service | ||||
data. The service region is described by value in one or more | ||||
<serviceBoundary> elements, each formatted according to a different | ||||
location profile. The client only processes the first element that | ||||
it can understand according to its list of supported location | ||||
profiles. Thus, the elements are alternative descriptions of the | ||||
same service region, not additive geometries. | ||||
This subsection describes the response message that provides the LoST | The server returns all suitable service regions, using all available | |||
client with the list of immediate child service identifiers based on | location profiles, so that intermediate caches have this information | |||
the service identifier provided by LoST client with respect to the | available for future queries. | |||
location information provided in the listService query. | ||||
The following example shows the response to the listServices query | 6.4.6. Service Boundaries by Reference: the <serviceBoundaryReference> | |||
example of Figure 8 listing the available services offered by the | Element | |||
LoST server starting with 'urn:service:sos.ambulance' and finishing | ||||
with 'urn:service:sos.suicide'. | ||||
<?xml version="1.0" encoding="UTF-8"?> | Since geodetic service boundaries may contain thousands of points and | |||
<response xmlns="urn:ietf:params:xml:ns:lost1"> | thus be quite large, clients may opt to conserve bandwidth and | |||
<serviceList status="200" message="OK" xml:lang="en"> | request a reference to the service boundary instead of the value | |||
urn:service:sos.ambulance | described in Section 6.4.5. The identifier of the service boundary | |||
urn:service:sos.animal-control | is returned in the <serviceBoundaryReference> element, along with a | |||
urn:service:sos.fire | LoST URL identifying the server from where it can be retrieved. The | |||
urn:service:sos.gas | actual value of the service boundary is then retrieved with the | |||
urn:service:sos.mountain | getServiceBoundary (Section 7) request. | |||
urn:service:sos.marine | ||||
urn:service:sos.physician | ||||
urn:service:sos.poison | ||||
urn:service:sos.police | ||||
urn:service:sos.suicide | ||||
</serviceList> | ||||
</response> | ||||
Figure 9: Example for the Response to a List Service Query | The identifier is a random token with at least 128 bits of entropy | |||
and can be assumed to be globally unique. The identifier uniquely | ||||
references a particular boundary; if the boundary changes, a new | ||||
identifier must be chosen. Because of these properties, a client | ||||
receiving a mapping response can simply check if it already has a | ||||
copy of the boundary with that identifier. If so, it can skip | ||||
checking with the server whether the boundary has been updated. | ||||
Since service boundaries are likely to remain unchanged for extended | ||||
periods of time, possibly exceeding the normal lifetime of the | ||||
service URL, this approach avoids refreshing the boundary information | ||||
even if the cached service response has gotten stale. | ||||
8. Status Code Definitions | 6.4.7. The Service Number | |||
Each response contains a <status> element that conveys a numeric | The service number is returned in the optional <serviceNumber> | |||
status code and a reason phrase indicating the success or failure of | element. It contains a string of digits, * and # that a user on a | |||
the response. The appearance of other elements in the response | device with a 12-key dial pad could use to reach that particular | |||
depends on the status code. Hence, different elements are used for | service. | |||
groups of status codes. | ||||
Status codes always have three digits; the list of status codes is | 6.4.8. Civic Address Validation | |||
meant to be extensible by IANA registration and follows the general | ||||
pattern of the Session Initiation Protocol (SIP) [22] and HTTP [14]. | ||||
The first digit indicates the type of response, with '2' signaling a | ||||
successful request, '3' a redirection, '4' a request failure due to | ||||
client behavior, and '5' a server failure. | ||||
If used within HTTP, LoST also utilizes the normal HTTP status codes. | A server can indicate in its response which civic address elements it | |||
However, the HTTP request can succeed, while the LoST request caused | has recognized as valid, which ones it has ignored and which ones it | |||
an error. All LoST status codes appear in HTTP 200 (OK) responses. | has checked and found to be invalid. Each element contains a list of | |||
For example, a LoST 404, 414 or 500 status would occur in an HTTP 200 | tokens separated by white space, enumerating the civic location | |||
response. | lables used in child elements of the <civicAddress> element. The | |||
<valid> element enumerates those civic address elements that have | ||||
been recognized as valid by the LoST server and that have been used | ||||
to determine the mapping. The <unchecked> elements enumerates the | ||||
civic address elements that the server did not check and that were | ||||
not used in determining the response. The <invalid> element | ||||
enumerate civic address elements that the server attempted to check, | ||||
but that did not match the other civic address elements found in the | ||||
<valid> list. | ||||
Temporary unavailability of the service should be indicated by an | The example (Figure 6) indicates that the tokens 'country', 'A1', | |||
HTTP 505 (Service Unavailable) status code. | 'A3', and 'A6' have been validated by the LoST server. The server | |||
considered the postal code 81675 in the <PC> element as not valid for | ||||
this location. | ||||
[Editor's Note: Does this make any sense or should all or some LoST | 6.4.9. Validity: The 'timeToLive' Attribute | |||
errors occur in a non-200 HTTP response?] | ||||
8.1. Informational 1xx | The timeToLive attribute contains the number of seconds the response | |||
is to be considered valid. The contents of this attribute is a | ||||
positive integer. See Section 4 regarding how this value is to be | ||||
utilized with a cache. [TBD: This could also be an absolute time.] | ||||
This document does not define informational status codes. | 7. Retrieving the Service Boundary via <getServiceBoundary> | |||
8.2. Successful 2xx | As discussed in Section 6.4.5, the <findService> response can return | |||
a globally unique identifier that can be used to retrieve the service | ||||
boundary, rather than returning the boundary by value. This is shown | ||||
in the example in Figure 8. The client can then retrieve the | ||||
boundary using the <getServiceBoundary> request and obtains the | ||||
boundary in the <getServiceBoundaryResponse>, illustrated in the | ||||
example in Section 7. The client issues the request to the server | ||||
identified in the 'server' attribute of the | ||||
<serviceBoundaryReference> element. | ||||
8.2.1. 200 OK | C: <?xml version="1.0" encoding="UTF-8"?> | |||
C: <findService xmlns="urn:ietf:params:xml:ns:lost1" | ||||
C: xmlns:p2="http://www.opengis.net/gml" recursive="true" | ||||
C: include="uri service serviceNumber displayName | ||||
C: serviceBoundaryReference"> | ||||
C: <location | ||||
C: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> | ||||
C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> | ||||
C: <p2:pos>40.809 -73.9612</p2:pos> | ||||
C: </p2:Point> | ||||
C: </location> | ||||
C: <service>urn:service:sos.police</service> | ||||
C: </findService> | ||||
The query completed successfully. | S: <?xml version="1.0" encoding="UTF-8"?> | |||
S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" | ||||
S: timeToLive="3600"> | ||||
S: <displayName xml:lang="en"> | ||||
S: New York City Police Department | ||||
S: </displayName> | ||||
S: <service>urn:service:sos.police</service> | ||||
S: <serviceBoundaryReference server="lost:nypd.example.com" | ||||
S: key="7214148E0433AFE2FA2D48003D31172E"/> | ||||
S: <uri>sip:nypd@example.com</uri> | ||||
S: <uri>xmpp:nypd@example.com</uri> | ||||
S: <serviceNumber>911</serviceNumber> | ||||
S: </findServiceResponse> | ||||
8.2.2. 201 Service Substitution | Figure 8: findService with Service Boundary Reference | |||
C: <?xml version="1.0" encoding="UTF-8"?> | ||||
C: <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1" | ||||
C: key="7214148E0433AFE2FA2D48003D31172E"/> | ||||
The service requested is not available for the location requested, | S: <?xml version="1.0" encoding="UTF-8"?> | |||
but the server is configured to provide a replacement service. | S: <getServiceBoundaryResponse | |||
S: xmlns="urn:ietf:params:xml:ns:lost1" | ||||
S: xmlns:p2="http://www.opengis.net/gml"> | ||||
S: | ||||
S: <serviceBoundary | ||||
S: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> | ||||
S: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | ||||
S: <p2:exterior> | ||||
S: <p2:LinearRing> | ||||
S: <p2:pos>40.701 -74.020</p2:pos> | ||||
S: <p2:pos>40.876 -73.926</p2:pos> | ||||
S: <p2:pos>40.797 -73.936</p2:pos> | ||||
S: <p2:pos>40.714 -73.984</p2:pos> | ||||
S: <p2:pos>40.701 -74.020</p2:pos> | ||||
S: </p2:LinearRing> | ||||
S: </p2:exterior> | ||||
S: </p2:Polygon> | ||||
S: </serviceBoundary> | ||||
S: | ||||
S: </getServiceBoundaryResponse> | ||||
8.3. Redirection 3xx | Figure 9: Requesting a Service Boundary with getServiceBoundary | |||
8.3.1. 301 Move Permanently | The <getServiceBoundary> request may also be used to retrieve service | |||
boundaries that are expressed as civic addresses, as illustrated in | ||||
Figure 10. | ||||
The requested location is being mapped by a different server and all | <?xml version="1.0" encoding="UTF-8"?> | |||
future requests for that location (and locations in the service area) | <getServiceBoundaryResponse | |||
should be directed to that server. | xmlns="urn:ietf:params:xml:ns:lost1"> | |||
<serviceBoundary | ||||
profile="urn:ietf:params:lost:location-profile:basic-civic"> | ||||
<civicAddress | ||||
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> | ||||
<country>US</country> | ||||
<A1>New York</A1> | ||||
<A3>New York</A3> | ||||
</civicAddress> | ||||
</serviceBoundary> | ||||
</getServiceBoundaryResponse> | ||||
8.3.2. 302 Moved Temporarily | Figure 10: Civic Address Service Boundary Response | |||
The requested location is being mapped by a different server, but | 8. List Services: <listServices> | |||
future requests should continue to use this server. | ||||
8.3.3. Example | A LoST client can ask a LoST server for the list of services it | |||
supports. The <listServices> query contains one or more <location> | ||||
elements, each from a different location profile (Section 9), and may | ||||
contain the <service> element. If the query contains the <service> | ||||
element the LoST server returns only immediate child services of the | ||||
queried service that are available for the provided location. If the | ||||
<service> element is absent, the LoST service returns all top-level | ||||
services available for the provided location that it knows about. | ||||
This is an example of an error message with a 302 status code: | A server responds to this query with a <listServicesResponse> | |||
response. This response has may contain <via> elements | ||||
(Section 6.4.1) and must contain a <serviceList> element, consisting | ||||
of a whitespace-separated list of service URNs. The query and | ||||
response are illustrated in Figure 11. | ||||
<?xml version="1.0" encoding="UTF-8"?> | C: <?xml version="1.0" encoding="UTF-8"?> | |||
<response xmlns="urn:ietf:params:xml:ns:lost1"> | C: <listServices | |||
<redirect status="302" | C: xmlns="urn:ietf:params:xml:ns:lost1" | |||
message="County-level routing" | C: xmlns:p2="http://www.opengis.net/gml" | |||
xml:lang="en" | C: recursive="false"> | |||
redirect="lost:co.lancaster.pa.us" | C: <location | |||
</response> | C: profile="urn:ietf:params:lost:location-profile:basic-civic"> | |||
C: <p2:Point id="point1" srsName="epsg:4326"> | ||||
C: <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> | ||||
C: </p2:Point> | ||||
C: </location> | ||||
C: <service>urn:service:sos</service> | ||||
C: </listServices> | ||||
8.4. Client Error 4xx | S: <?xml version="1.0" encoding="UTF-8"?> | |||
S: <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1"> | ||||
S: <serviceList> | ||||
S: urn:service:sos.ambulance | ||||
S: urn:service:sos.animal-control | ||||
S: urn:service:sos.fire | ||||
S: urn:service:sos.gas | ||||
S: urn:service:sos.mountain | ||||
S: urn:service:sos.marine | ||||
S: urn:service:sos.physician | ||||
S: urn:service:sos.poison | ||||
S: urn:service:sos.police | ||||
S: urn:service:sos.suicide | ||||
S: </serviceList> | ||||
S: </listServicesResponse> | ||||
Figure 11: ListService Query Example | ||||
8.4.1. 400 Bad Request | 9. Location Profiles | |||
The request could not be understood due to malformed syntax. | Currently, LoST uses location information in <location> elements in | |||
requests and <serviceBoundary> elements in responses. Such location | ||||
information may be expressed in a variety of ways. This variety can | ||||
cause interoperability problems where a request or response contains | ||||
location information in a format not understood by the server or | ||||
client, respectively. To achieve interoperability, LoST defines two | ||||
must-implement baseline location profiles to define the manner in | ||||
which location information is transmitted and makes it possible to | ||||
standardize other profiles in the future. The two baseline profiles | ||||
are: | ||||
8.4.2. 403 Forbidden | geodetic-2d: a simple profile for two-dimensional geodetic location | |||
information, described in Section 9.2); | ||||
The server understood the request, but is refusing to fulfill it. | civic: a profile consisting of civic address location information, | |||
Authorization will not help, and the request SHOULD NOT be repeated. | described in Section 9.3. | |||
8.4.3. 404 Not Found | Requests and responses containing <location> or <serviceBoundary> | |||
elements MUST contain location information in exactly one of the two | ||||
baseline profiles, in addition to zero or more additional profiles. | ||||
The ordering of location information indicates a preference on the | ||||
part of the sender. | ||||
The server has definitive information that there is no service | Standards action may create other profiles. A location profile MUST | |||
mapping for the location specified. | define: | |||
8.4.4. 414 Location Error | 1. The token identifying it in the LoST location profile registry; | |||
The location provided does not exist or fields within the location | 2. The formal definition of the XML to be used in requests, i.e., an | |||
information are contradictory. | enumeration and definition of the XML child elements of the | |||
<location> element; | ||||
8.4.5. Example | 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 | ||||
the <serviceBoundary> element; | ||||
The first example shows an error message with a 414 status code that | 4. The declaration of whether geodetic-2d or civic is to be used as | |||
is attached to the response message indicating that there was a | the baseline profile. It is necessary to explicitly declare the | |||
problem with the postal code: | baseline profile as future profiles may be combinations of | |||
geodetic and civic location information. | ||||
<?xml version="1.0" encoding="UTF-8"?> | 9.1. Location Profile Usage | |||
<response xmlns="urn:ietf:params:xml:ns:lost1"> | ||||
<result status="250" message="Default Route" | ||||
xml:lang="en" timeToLive="10000"> | ||||
<displayName xml:lang="en"> | ||||
New York City Police Department | ||||
</displayName> | ||||
<service>unknown</service> | ||||
<serviceBoundary> | ||||
<civicLocation> | ||||
<country>US</country> | ||||
<A1>New York</A1> | ||||
<A3>New York</A3> | ||||
</civicLocation> | ||||
</serviceBoundary> | ||||
<uri>sip:nypd@example.com</uri> | ||||
<uri>xmpp:nypd@example.com</uri> | ||||
<service-number>911</service-number> | ||||
</result> | ||||
<failure status="414" message="Address error" xml:lang="en"> | ||||
<cause name="PC" | ||||
message="postal code is outside of service boundary" | ||||
xml:lang="en" /> | ||||
</failure> | ||||
</response> | ||||
The second example shows an error message with a 414 status code that | A location profile is identified by a URN in the | |||
is attached to the response message indicating that there was a | urn:ietf:params:lost:location-profile registry. (Note that this is | |||
problem with the provided geospatial location information: | not an XML schema or namespace identifier.) Clients send location | |||
information compliant with a location profile, and servers respond | ||||
with location information compliant with that same location profile. | ||||
<?xml version="1.0" encoding="UTF-8"?> | When a LoST client sends a request which provides location | |||
<response | information, it contains one or more <location> elements. Each of | |||
xmlns="urn:ietf:params:xml:ns:lost1" | these elements contains location information compliant with a | |||
xmlns:p2="http://www.opengis.net/gml" > | location profile and specifies which profile has been used in the | |||
<result status="250" message="Default PSAP" | 'profile' attribute. This allows the client to convey location | |||
xml:lang="en" timeToLive="1000"> | information for multiple location profiles in the same request. | |||
<displayName xml:lang="en"> | ||||
New York City Police Department | ||||
</displayName> | ||||
<service>urn:service:sos.police</service> | ||||
<serviceBoundary> | ||||
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | ||||
<p2:exterior> | ||||
<p2:LinearRing> | ||||
<p2:pos>37.775 -122.4194</p2:pos> | ||||
<p2:pos>37.555 -122.4194</p2:pos> | ||||
<p2:pos>37.555 -122.4264</p2:pos> | ||||
<p2:pos>37.775 -122.4264</p2:pos> | ||||
<p2:pos>37.775 -122.4194</p2:pos> | ||||
</p2:LinearRing> | ||||
</p2:exterior> | ||||
</p2:Polygon> | ||||
</serviceBoundary> | ||||
<uri>sip:nypd@example.com</uri> | ||||
<uri>xmpp:nypd@example.com</uri> | ||||
<serviceNumber>911</serviceNumber> | ||||
</result> | ||||
<failure status="414" | ||||
message="Invalide Goegraphic Location" xml:lang="en"> | ||||
<cause name="p2:coordinates" | ||||
message="invalid latitude" xml:lang="en" /> | ||||
</failure> | ||||
</response> | ||||
8.5. Server Error 5xx | When a LoST server sends a response which contains location | |||
information, it uses the <serviceBoundary> elements much like the | ||||
client uses the <location> elements. Each <serviceBoundary> element | ||||
contains location information conformant to the location profile | ||||
specified in the 'profile' attribute. This allows the server to send | ||||
location information compliant with multiple location profiles. | ||||
8.5.1. 500 Server Internal Error | Using the location profiles defined in this document, the following | |||
rules insure basic interoperatiblity between clients and servers: | ||||
The server encountered an unexpected condition that prevented it from | 1. A client MUST be capable of understanding the response for the | |||
fulfilling the request. The client MAY retry the request after | baseline profiles it used in the request. | |||
several seconds. | ||||
8.5.2. 501 Service Not Implemented | 2. If a client sends location information conformant to any location | |||
profile other than geodetic-2d or civic, it MUST also send, in | ||||
the same request, location information conformant to one of the | ||||
baseline profiles. Otherwise, the server might not be able to | ||||
understand the request. | ||||
The server does not implement mapping for the service requested and | 3. Servers MUST implement the geodetic-2d and civic profiles. | |||
cannot provide an alternate service. | ||||
8.5.3. 504 Server Time-Out | 4. A server ignores any location information using non-baseline | |||
profiles it does not understand. | ||||
A server time-out occurs if the server contacted tries to recursively | 5. If a server receives a request that only contains location | |||
resolve the query, but cannot get an answer within the time limit set | information using profiles it does not understand, the server | |||
for the query. | responds with a <locationProfileError> (Section 10.2). | |||
8.5.4. Example | These rules enable the use of location profiles not yet specified, | |||
while ensuring baseline interoperability. Take, for example, this | ||||
scenario. Client X has had its firmware upgraded to support the | ||||
uber-complex-3D location profile. Client X sends location | ||||
information to Server Y, which does not understand the | ||||
uber-complex-3D location profile. If Client X also sends location | ||||
information using the geodetic-2D baseline profile, then Server Y | ||||
will still be able to understand the request and provide an | ||||
understandable response, though with location information that might | ||||
not be as precise or expressive as desired. This is possible because | ||||
both Client X and Server Y understand the baseline profile. The | ||||
following transaction, where the XML sent by the client is prepended | ||||
with 'C:' and the XML sent by the server is prepended with 'S:', | ||||
demonstrates this: | ||||
This is an example of an error message with a 500 status code: | C: <?xml version="1.0" encoding="UTF-8"?> | |||
C: <findService xmlns="urn:ietf:params:xml:ns:lost1" | ||||
C: xmlns:p2="http://www.opengis.net/gml" | ||||
C: recursive="true" include="uri serviceNumber"> | ||||
C: <location | ||||
C: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> | ||||
C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> | ||||
C: <p2:pos>40.8089897 -73.9612492</p2:pos> | ||||
C: </p2:Point> | ||||
C: </location> | ||||
C: <location | ||||
C: profile=" | ||||
C: urn:ietf:params:lost:location-profile:uber-complex-3d"> | ||||
C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> | ||||
C: <p2:pos>37.775 -122.422 25</p2:pos> | ||||
C: </p2:Point> | ||||
C: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | ||||
C: <p2:exterior> | ||||
C: <p2:LinearRing> | ||||
C: <p2:pos>40.80 -73.96 24</p2:pos> | ||||
C: <p2:pos>40.81 -73.95 27</p2:pos> | ||||
C: <p2:pos>40.80 -73.96 24</p2:pos> | ||||
C: </p2:LinearRing> | ||||
C: </p2:exterior> | ||||
C: </p2:Polygon> | ||||
C: </location> | ||||
C: <service>urn:service:sos.police</service> | ||||
C: </findService> | ||||
<?xml version="1.0" encoding="UTF-8"?> | S: <?xml version="1.0" encoding="UTF-8"?> | |||
<response xmlns="urn:ietf:params:xml:ns:lost1"> | S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" | |||
<status code="500">Server failure</status> | S: xmlns:p2="http://www.opengis.net/" timeToLive="3600"> | |||
</response> | S: <locationProfileError | |||
S: unsupportedProfiles=" | ||||
S: urn:ietf:params:lost:location-profile:uber-complex-3d" | ||||
S: message="Too sophisticated for us." xml:lang="en"/> | ||||
S: <displayName xml:lang="en"> | ||||
S: New York City Police Department | ||||
S: </displayName> | ||||
S: <service>urn:service:sos.police</service> | ||||
S: <serviceBoundary | ||||
S: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> | ||||
S: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> | ||||
S: <p2:exterior> | ||||
S: <p2:LinearRing> | ||||
S: <p2:pos>40.701 -74.020</p2:pos> | ||||
S: <p2:pos>40.876 -73.926</p2:pos> | ||||
S: <p2:pos>40.797 -73.936</p2:pos> | ||||
S: <p2:pos>40.714 -73.984</p2:pos> | ||||
S: <p2:pos>40.701 -74.020</p2:pos> | ||||
S: </p2:LinearRing> | ||||
S: </p2:exterior> | ||||
S: </p2:Polygon> | ||||
S: </serviceBoundary> | ||||
S: <uri>sip:nypd@example.com</uri> | ||||
S: </findServiceResponse> | ||||
9. LoST Transport | Figure 12: Example of a findServices query with baseline profile | |||
interoperability | ||||
LoST needs an underlying protocol transport mechanisms to carry | 9.2. Two Dimensional Geodetic Profile | |||
requests and responses. This document defines the use of LoST over | ||||
HTTP and HTTP-over-TLS; other mechanisms are left to future | ||||
documents. The available transport mechanisms are indicated in the | ||||
LoST U-NAPTR DNS resource record. In protocols that support content | ||||
type indication, LoST uses the media type application/lost+xml. | ||||
When using HTTP [14] and HTTP-over-TLS [15], LoST requests use the | The geodetic-2d location profile is identified by geodetic-2d. | |||
HTTP POST method. All HTTP responses are applicable. The HTTP URL | Clients use this profile by placing a GML [13] <position> element | |||
is derived from the LoST URL via U-NAPTR translation, as discussed in | within the <location> element. This is defined by the 'point2D' | |||
Section 4. | pattern in the LoST schema (see Section 12). | |||
10. LoST Uniform Resource Locators | Servers use this profile by placing a GML [13] <Polygon> element | |||
within the <serviceBoundary> element. This is defined by the | ||||
'polygon' pattern in the LoST schema (see Section 12). | ||||
LoST Uniform Resource Locators (URLs) follow the format of URLs | 9.3. Basic Civic Profile | |||
defined in RFC 3986 [9], with the following ABNF: | ||||
LoST-URI = "lost:" host | The basic-civic location profile is identified by the token 'civic'. | |||
Clients use this profile by placing a <civicAddress> element, defined | ||||
in [11], within the <location> element. | ||||
'host' is defined in Section 3.2.2 of RFC 3986 [9]. | Servers use this profile by placing a <civicAddress> element, defined | |||
in [11], within the <serviceBoundary> element. | ||||
An example is 'lost:lostserver.example.com' | 10. Error Handling | |||
11. Example | Errors are indicated by error-specific elements. Depending on the | |||
nature of the error, the error element may occur along with other | ||||
response elements, indicating that the request was only partially | ||||
satisfied and that not all information in the request was processed | ||||
correctly. Errors labeled as fatal means | ||||
After performing link layer attachment and end host performs stateful | 10.1. Basic Errors | |||
address autoconfiguration (in our example) using DHCP. Then, DHCP | ||||
provides the end host with civic location as described in [19]. | ||||
+--------+---------------+ | LoST defines a pattern for errors, defined as "errors" in the Relax | |||
| CAtype | CAvalue | | NG schema. This pattern defines a 'message' attribute containing | |||
+--------+---------------+ | human readable text and an 'xml:lang' attribute denoting the language | |||
| 0 | US | | of the human readable text. | |||
| 1 | New York | | ||||
| 3 | New York | | ||||
| 6 | Broadway | | ||||
| 22 | Suite 75 | | ||||
| 24 | 10027-0401 | | ||||
+--------+---------------+ | ||||
Figure 14: DHCP Civic Information Example | LoST defines the following elements as following this pattern: | |||
Additionally, DHCP may provide information about the LoST server that | badRequest The server could not parse or otherwise understand a | |||
can be contacted. Alternatively, an additional step of indirection | request. This is a top-level element, and is returned if the | |||
is possible, for example by having DHCP return a domain name that has | server did not understand the outermost LoST XML element | |||
to be resolved to one or more IP addresses hosting LoST servers. | identifying the request. | |||
Both at attachment time and call time, the client places a LoST | serviceSubstitution The server substituted one service for another. | |||
request, including its civic location and the desired service. The | See Section 6.4.4. | |||
request is shown below: | ||||
<?xml version="1.0" encoding="UTF-8"?> | 10.2. Response Errors | |||
<findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1" | ||||
validate="false" operation="recursive"> | ||||
<locationInfo> | ||||
<civicLocation> | ||||
<country>US</country> | ||||
<A1>New York</A1> | ||||
<A3>New York</A3> | ||||
<A6>Broadway</A6> | ||||
<LOC>Suite 75</LOC> | ||||
<PC>10027-0401</PC> | ||||
</civicLocation> | ||||
</locationInfo> | ||||
<service>urn:service:sos.police</service> | ||||
</findServiceByLocation> | ||||
Mapping Request | LoST defines a pattern for errors that may generated by referrent | |||
Since the contacted LoST server has the requested information | LoST serves queried on behalf of seekers by a resolving LoST server. | |||
available the following response is returned. The <displayName> | This pattern builds on the basic errors pattern (Section 10.1). It | |||
element indicates, as a human readable display string, that the 'New | also provides the option of specifying the source server using the | |||
York City Police Department' is responsible for the given | 'source' attribute, as well as specifying the query that caused the | |||
geographical area. The indicated URI allows the user to start | error. | |||
communication using SIP or XMPP. The <validation> element indicates | ||||
which parts of the civic address were matched successfully against a | ||||
database and represent a known address. Other parts of the address, | ||||
here, the suite number, were ignored and not validated. The | ||||
<serviceBoundary> element indicates that all of New York City would | ||||
result in the same response. The <serviceNumber> element indicates | ||||
that the service can be reached via the emergency service number 911. | ||||
<?xml version="1.0" encoding="UTF-8"?> | LoST defines the following elements as following this pattern: | |||
<response xmlns="urn:ietf:params:xml:ns:lost1"> | ||||
<result status="200" message="OK" xml:lang="en" timeToLive="10000"> | ||||
<displayName xml:lang="en"> | ||||
New York City Police Department | ||||
</displayName> | ||||
<service>unknown</service> | ||||
<serviceBoundary> | ||||
<civicLocation> | ||||
<country>US</country> | ||||
<A1>New York</A1> | ||||
<A3>New York</A3> | ||||
</civicLocation> | ||||
</serviceBoundary> | ||||
<uri>sip:nypd@example.com</uri> | ||||
<uri>xmpp:nypd@example.com</uri> | ||||
<service-number>911</service-number> | ||||
</result> | ||||
</response> | ||||
Mapping Response | forbidden The server refused to send an answer. | |||
12. Deployment Methods | notFound The server could not find an answer to the query. | |||
Because services for emergency contact resolution may differ | serviceNotImplemented The requested service is not implemented. | |||
depending on local or service needs, this document only specifies the | ||||
"wire format" for LoST services and explicitly leaves open the | ||||
possibility for many different types of deployment. | ||||
For instance: | internalError The server could not satisfy a request due to | |||
misconfiguration or other operational and non-protocol related | ||||
reasons. | ||||
During discovery, a client may be directed to issue all queries to | serverTimeout A time out occurred before an answer was received. | |||
an LoST service completely authoritative for a given jurisdiction. | ||||
A client may be directed to issue queries to an LoST server that | serverError An answer was received but it could not be parsed or | |||
acts as a reflector. In such a case, the LoST server analyzes the | otherwise understood. | |||
query to determine the best server to which to refer the client. | ||||
Or the client may be directed to a server that performs further | locationProfileError A location profile in the query given is not | |||
resolution on behalf of the client. | recognized. The element may also have an 'unsupportedProfiles' | |||
attribute, which contains a whitespace separated list of profile | ||||
URNs. See Section 9. | ||||
A LoST service may also be represented by multiple LoST servers, | 10.3. Redirects | |||
either grouped together or at multiple network locations. Using | ||||
S-NAPTR [24], clients may be given a list of multiple servers to | ||||
which queries can be sent for a single service. | ||||
For instance, the service at emergency.example.com may advertise LoST | LoST defines a pattern for redirect responses. This pattern builds | |||
service at local1.emergency.example.com, | on the basic error pattern (Section 10.1) and includes a 'url' | |||
local2.emergency.example.com, and master.emergency.example.com. Each | attribute indicating the LoST URL that the client should be | |||
server may given a different preference. In this case, 'local-1' and | contacting next. | |||
'local-2' may be given a lower preference (more preferred) than | ||||
'master', which might be a busier server or located further away. | ||||
+-----------+ pref 10 +-----------+ | Currently, LoST only defines the <redirect> element along this | |||
| |-------------------->+ | | pattern. | |||
| client |------ | local-1 | | ||||
| |--- \ | | | ||||
+-----------+ \ \ +-----------+ | ||||
\ \ | ||||
\ \ +-----------+ | ||||
\ \ pref 10 | | | ||||
\ --------->| local-2 | | ||||
\ | | | ||||
\ +-----------+ | ||||
\ | ||||
\ +-----------+ | ||||
\ pref 20 | | | ||||
------------------------->| master | | ||||
| | | ||||
+-----------+ | ||||
13. Relax NG Schema | 11. LoST Transport | |||
LoST needs an underlying protocol transport mechanisms to carry | ||||
requests and responses. This document defines the use of LoST over | ||||
HTTP and HTTP-over-TLS; other mechanisms are left to future | ||||
documents. The available transport mechanisms are determined through | ||||
the use of the LoST U-NAPTR application. In protocols that support | ||||
content type indication, LoST uses the media type application/ | ||||
lost+xml. | ||||
When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP | ||||
POST method. All HTTP responses are applicable. The HTTP URL is | ||||
derived from the LoST URL via U-NAPTR application, as discussed in | ||||
Section 5. | ||||
12. Relax NG Schema | ||||
This section provides the Relax NG schema used by LoST protocol in | This section provides the Relax NG schema used by LoST protocol in | |||
the compact form. The verbose form is included in Appendix A. | the compact form. The verbose form is included in Appendix A. | |||
default namespace = "urn:ietf:params:xml:ns:lost1" | default namespace = "http://www.opengis.net/gml" | |||
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" | namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" | |||
namespace ns1 = "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" | namespace ns1 = "urn:ietf:params:xml:ns:lost1" | |||
namespace ns2 = "http://www.opengis.net/gml" | ||||
## | ## | |||
## Location-to-Service Translation Protocol (LoST) | ## Location-to-Service Translation Protocol (LoST) | |||
## | ## | |||
## A LoST XML instance has three "root" types: | ## A LoST XML instance has three request types, each with | |||
## the findServiceByLocation query, the listServices query, | ## a cooresponding response type: find service, list services, | |||
## and the response to these queries. | ## and get service boundary. | |||
## | ## | |||
start = findServiceByLocation | listServices | response | start = | |||
findService | ||||
| listServices | ||||
| getServiceBoundary | ||||
| findServiceResponse | ||||
| listServicesResponse | ||||
| getServiceBoundaryResponse | ||||
## | ## | |||
## The queries. | ## The queries. | |||
## | ## | |||
div { | div { | |||
findServiceByLocation = | findService = | |||
element findServiceByLocation { | element ns1:findService { | |||
query, | query, | |||
attribute validate { xsd:boolean >> a:defaultValue [ "false" ] }? | attribute include { | |||
list { | ||||
("uri" | ||||
| "serviceNumber" | ||||
| "displayName" | ||||
| "service" | ||||
| "valid" | ||||
| "invalid" | ||||
| "unchecked" | ||||
| "serviceBoundary" | ||||
| "serviceBoundaryReference")* | ||||
} | ||||
>> a:defaultValue [ "uri serviceNumber" ] | ||||
}? | ||||
} | ||||
listServices = element ns1:listServices { query } | ||||
getServiceBoundary = | ||||
element ns1:getServiceBoundary { | ||||
serviceBoundaryKey, extensionPoint | ||||
} | } | |||
listServices = element listServices { query } | ||||
} | } | |||
## | ## | |||
## The response. | ## The responses. | |||
## | ## | |||
div { | div { | |||
response = | findServiceResponse = | |||
element response { | element ns1:findServiceResponse { | |||
via, | ||||
((locationProfileError?, serviceSubstitution?, serviceResult) | ||||
| badRequest | ||||
| internalError | ||||
| forbidden | ||||
| notFound | ||||
| serviceNotImplemented | ||||
| serverTimeout | ||||
| serverError | ||||
| movedPermenantly | ||||
| movedTemporarily | ||||
| iterativeSearchExhausted), | ||||
extensionPoint | ||||
} | ||||
listServicesResponse = | ||||
element ns1:listServicesResponse { | ||||
via, | ||||
((locationProfileError?, | ||||
element ns1:serviceList { | ||||
list { xsd:anyURI* } | ||||
})), | ||||
extensionPoint | ||||
} | ||||
getServiceBoundaryResponse = | ||||
element ns1:getServiceBoundaryResponse { | ||||
(serviceBoundary | ||||
| badRequest | ||||
| internalError | ||||
| forbidden | ||||
| notFound), | ||||
extensionPoint | ||||
} | ||||
} | ||||
## | ## | |||
## 2xx responses. | ## A pattern common to some of the queries. | |||
## | ## | |||
(result | div { | |||
| element serviceList { | query = | |||
list { xsd:anyURI* }, | element ns1:location { locationInformation }+, | |||
status | element ns1:service { xsd:anyURI }?, | |||
})?, | extensionPoint, | |||
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? | ||||
} | ||||
## | ## | |||
## 3xx, 4xx, and 4xx responses. | ## Location Information | |||
## | ## | |||
((error | redirect | failure)?), | div { | |||
extensionPoint | locationInformation = | |||
extensionPoint+, | ||||
attribute profile { xsd:anyURI } | ||||
} | } | |||
## | ||||
## Service Boundary | ||||
## | ||||
div { | ||||
serviceBoundary = element ns1:serviceBoundary | ||||
{ locationInformation }+ | ||||
} | } | |||
## | ## | |||
## Query pattern. | ## Service Boundary Key | |||
## | ## | |||
div { | div { | |||
query = | serviceBoundaryKey = | |||
element locationInfo { anyElement* }, | attribute key { | |||
element service { xsd:anyURI }, | xsd:string { pattern = "[a-zA-Z0-9/+=]+" } | |||
extensionPoint, | } | |||
[ a:defaultValue [ "recursive" ] ] attribute operation { text }? | ||||
} | } | |||
## | ## | |||
## A result. | ## Via - list of places through which information flowed | |||
## | ## | |||
div { | div { | |||
via = element ns1:via { xsd:anyURI }* | ||||
} | ||||
## | ## | |||
## 2xx response. | ## Time-to-live pattern | |||
## | ## | |||
result = | div { | |||
element result { | timeToLive = attribute timeToLive { xsd:positiveInteger } | |||
element displayName { | } | |||
## | ||||
## A QName list | ||||
## | ||||
div { | ||||
qnameList = list { xsd:QName* } | ||||
} | ||||
## | ||||
## A location-to-service result. | ||||
## | ||||
div { | ||||
serviceResult = | ||||
element ns1:displayName { | ||||
xsd:string, | xsd:string, | |||
attribute xml:lang { xsd:language } | attribute xml:lang { xsd:language } | |||
}?, | }?, | |||
element service { xsd:anyURI }, | element ns1:service { xsd:anyURI }?, | |||
element serviceBoundary { | (serviceBoundary | |||
(civicLocation, polygon?) | (civicLocation?, polygon) | | element ns1:serviceBoundaryReference { serviceBoundaryKey })?, | |||
}?, | element ns1:uri { xsd:anyURI }*, | |||
element uri { xsd:anyURI }+, | element ns1:serviceNumber { | |||
element serviceNumber { | ||||
xsd:string { pattern = "[0-9]+" } | xsd:string { pattern = "[0-9]+" } | |||
}?, | }?, | |||
element validation { | element ns1:valid { qnameList }?, | |||
list { xsd:QName* } | element ns1:invalid { qnameList }?, | |||
}?, | element ns1:unchecked { qnameList }?, | |||
extensionPoint, | extensionPoint, | |||
attribute timeToLive { xsd:positiveInteger }, | timeToLive, | |||
status | message | |||
} | ||||
} | } | |||
## | ## | |||
## Non-result responses. | ## Basic Errors | |||
## | ## | |||
div { | div { | |||
## | ## | |||
## 5xx response. | ## Error pattern. | |||
## | ## | |||
error = element error { status, extensionPoint } | error = message, extensionPoint | |||
badRequest = element ns1:badRequest { error } | ||||
internalError = element ns1:internalError { error } | ||||
serviceSubstitution = element ns1:serviceSubstitution { error } | ||||
} | ||||
## | ||||
## Recursion Errors. | ||||
## | ||||
div { | ||||
## | ## | |||
## 3xx response. | ## Recursion error. | |||
## | ## | |||
redirect = | recursionError = | |||
element redirect { | attribute failedReferral { xsd:anyURI }?, | |||
status, | (findService | listServices | getServiceBoundary)?, | |||
attribute redirect { xsd:anyURI }, | error | |||
extensionPoint | forbidden = | |||
element ns1:forbidden { recursionError }, | ||||
timeToLive | ||||
notFound = | ||||
element ns1:notFound { recursionError }, | ||||
timeToLive | ||||
serviceNotImplemented = | ||||
element ns1:serviceNotImplemented { recursionError }, | ||||
timeToLive | ||||
serverTimeout = | ||||
element ns1:serverTimeout { recursionError }, | ||||
timeToLive | ||||
serverError = | ||||
element ns1:serverError { recursionError }, | ||||
timeToLive | ||||
locationProfileError = | ||||
element ns1:locationProfileError { | ||||
attribute unsupportedProfiles { | ||||
list { xsd:anyURI* } | ||||
}, | ||||
recursionError | ||||
} | ||||
} | } | |||
## | ## | |||
## 4xx response. | ## Redirects. | |||
## | ## | |||
failure = | div { | |||
element failure { | ||||
status, | ## | |||
element cause { | ## Redirect pattern | |||
attribute name { xsd:QName }, | ## | |||
attribute message { xsd:string }, | redirect = | |||
attribute xml:lang { xsd:language } | attribute redirect { xsd:anyURI }, | |||
}*, | error | |||
extensionPoint | movedPermenantly = element ns1:movedPermanently { redirect } | |||
} | movedTemporarily = | |||
element ns1:movedTemporarily { redirect }, | ||||
timeToLive | ||||
iterativeSearchExhausted = | ||||
element ns1:iterativeSearchExhausted { redirect }, | ||||
timeToLive | ||||
} | } | |||
## | ## | |||
## Status pattern. | ## Message pattern. | |||
## | ## | |||
div { | div { | |||
status = | message = | |||
attribute status { xsd:positiveInteger }, | ||||
attribute extendedStatus { xsd:positiveInteger }?, | ||||
(attribute message { xsd:string }, | (attribute message { xsd:string }, | |||
attribute xml:lang { xsd:language })? | attribute xml:lang { xsd:language })? | |||
} | } | |||
## | ## | |||
## Patterns for inclusion of elements from schemas in | ## Patterns for inclusion of elements from schemas in | |||
## other namespaces. | ## other namespaces. | |||
## | ## | |||
div { | div { | |||
## | ## | |||
## Any element not in the LoST namespace. | ||||
## | ||||
notLost = element * - (ns1:* | ns1:*) { anyElement } | ||||
## | ||||
## A wildcard pattern for including any element | ## A wildcard pattern for including any element | |||
## from any other namespace. | ## from any other namespace. | |||
## | ## | |||
anyElement = | anyElement = | |||
element * { | (element * { anyElement } | |||
(attribute * { text } | | attribute * { text } | |||
| text | | text)* | |||
| anyElement)* | ||||
} | ||||
## | ## | |||
## A point where future extensions | ## A point where future extensions | |||
## (elements from other namesapces) | ## (elements from other namespaces) | |||
## can be added. | ## can be added. | |||
## | ## | |||
extensionPoint = anyElement* | extensionPoint = notLost* | |||
## | ## | |||
## A pattern to include the GEOPRIV civil location elements. | ## A 2D point from GML. | |||
## | ## | |||
civicAddress = | point2d = | |||
element ns1:* { | element position { | |||
(attribute * { text } | element Point { | |||
| text | attribute srsName { "urn:ogc:def:crs:EPSG:4326" }, | |||
| anyElement)* | element pos { text } | |||
} | ||||
} | } | |||
## | ## | |||
## A definition of civic location from GEOPRIV. | ## A Linear Ring from GML. | |||
## | ## | |||
civicLocation = element civicLocation { civicAddress*, anyElement* } | linearRing = | |||
element LinearRing { | ||||
element pos { text } | ||||
} | ||||
## | ## | |||
## A pattern to include GML elements. | ## A Polygon from GML. | |||
## | ## | |||
GML = | ||||
element ns2:* { | ||||
(attribute * { text } | ||||
| text | ||||
| anyElement)* | ||||
} | ||||
polygon = | polygon = | |||
element ns2:Polygon { | element Polygon { | |||
attribute * { text }*, | attribute srsName { "urn:ogc:def:crs:EPSG:4979" }, | |||
GML | element exterior { linearRing }, | |||
element interior { linearRing }* | ||||
} | } | |||
} | } | |||
14. Internationalization Considerations | 13. Internationalization Considerations | |||
This mechanism is largely for passing protocol information from one | This mechanism is largely for passing protocol information from one | |||
subsystem to another; as such, most of its elements are tokens not | subsystem to another; as such, most of its elements are tokens not | |||
meant for direct human consumption. If these tokens are presented to | meant for direct human consumption. If these tokens are presented to | |||
the end user, some localization may need to occur. The content of | the end user, some localization may need to occur. The content of | |||
the <displayName> element may be displayed to the end user, and it is | the <displayName> element and the 'message' attributes may be | |||
thus a complex type designed for this purpose. | displayed to the end user, and they are thus a complex types designed | |||
for this purpose. | ||||
15. IANA Considerations | LoST exchanges information using XML. All XML processors are | |||
required to understand UTF-8 and UTF-16 encodings, and therefore all | ||||
LoST clients and servers MUST understand UTF-8 and UTF-16 encoded | ||||
XML. Additionally, LoST servers and clients MUST NOT encode XML with | ||||
encodings other than UTF-8 or UTF-16. | ||||
15.1. Content-type registration for 'application/lost+xml' | 14. IANA Considerations | |||
14.1. U-NAPTR Registrations | ||||
This document registers the following U-NAPTR application service | ||||
tag: | ||||
Application Service Tag: LoST | ||||
Defining Publication: The specification contained within this | ||||
document. | ||||
This document registers the following U-NAPTR application protocol | ||||
tags: | ||||
o | ||||
Application Protocol Tag: http | ||||
Defining Publication: RFC 2616 [3] | ||||
o | ||||
Application Protocol Tag: https | ||||
Defining Publication: RFC 2818 [5] | ||||
14.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 [13] and guidelines in RFC | according to the procedures of RFC 4288 [9] and guidelines in RFC | |||
3023 [12]. | 3023 [6]. | |||
MIME media type name: application | MIME media type name: application | |||
MIME subtype name: lost+xml | MIME subtype name: lost+xml | |||
Mandatory parameters: none | Mandatory parameters: none | |||
Optional parameters: charset | Optional parameters: charset | |||
Indicates the character encoding of enclosed XML. | Indicates the character encoding of enclosed XML. | |||
Encoding considerations: | Encoding considerations: | |||
Uses XML, which can employ 8-bit characters, depending on the | Uses XML, which can employ 8-bit characters, depending on the | |||
character encoding used. See RFC 3023 [12], Section 3.2. | character encoding used. See RFC 3023 [6], Section 3.2. | |||
Security considerations: | Security considerations: | |||
This content type is designed to carry LoST protocol payloads. | This content type is designed to carry LoST protocol payloads. | |||
Interoperability considerations: None | Interoperability considerations: None | |||
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please | Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please | |||
replace XXXX with the RFC number of this specification.] this | replace XXXX with the RFC number of this specification.] this | |||
document | document | |||
skipping to change at page 35, line 26 | skipping to change at page 40, line 9 | |||
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> | |||
15.2. LoST Relax NG Schema Registration | 14.3. LoST Relax NG Schema Registration | |||
URI: urn:ietf:params:xml:ns:lost | URI: urn:ietf:params:xml:ns:lost | |||
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | |||
(Hannes.Tschofenig@siemens.com). | (Hannes.Tschofenig@siemens.com). | |||
Relax NG Schema: The Relax NG schema to be registered is contained | Relax NG Schema: The Relax NG schema to be registered is contained | |||
in Section 13. Its first line is | in Section 12. Its first line is | |||
default namespace = "urn:ietf:params:xml:ns:lost1" | default namespace = "urn:ietf:params:xml:ns:lost1" | |||
and its last line is | and its last line is | |||
} | } | |||
15.3. LoST Namespace Registration | 14.4. LoST Namespace Registration | |||
URI: urn:ietf:params:xml:ns:lost | URI: urn:ietf:params:xml:ns:lost | |||
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig | |||
(Hannes.Tschofenig@siemens.com). | (Hannes.Tschofenig@siemens.com). | |||
XML: | XML: | |||
BEGIN | BEGIN | |||
<?xml version="1.0"?> | <?xml version="1.0"?> | |||
skipping to change at page 36, line 35 | skipping to change at page 41, line 6 | |||
<h1>Namespace for LoST</h1> | <h1>Namespace for LoST</h1> | |||
<h2>urn:ietf:params:xml:ns:lost</h2> | <h2>urn:ietf:params:xml:ns:lost</h2> | |||
<p>See <a href="[URL of published RFC]">RFCXXXX | <p>See <a href="[URL of published RFC]">RFCXXXX | |||
[NOTE TO IANA/RFC-EDITOR: | [NOTE TO IANA/RFC-EDITOR: | |||
Please replace XXXX with the RFC number of this | Please replace XXXX with the RFC number of this | |||
specification.]</a>.</p> | specification.]</a>.</p> | |||
</body> | </body> | |||
</html> | </html> | |||
END | END | |||
15.4. Registration Template | 14.5. Registration Template | |||
This registration template is in accordance with [8]. | This registration template is in accordance with [4]. | |||
URL scheme name: | URL scheme name: | |||
lost | lost | |||
URL scheme syntax: | URL scheme syntax: | |||
See Section 10 | See Section 5 | |||
Character encoding considerations: | Character encoding considerations: | |||
See Section 10 | See Section 5 | |||
Intended Use: | Intended Use: | |||
The intended usage is described in this document. | The intended usage is described in this document. | |||
Application and protocols which use this scheme: | Application and protocols which use this scheme: | |||
The usage of the LoST URL scheme is targeted for this document and | The usage of the LoST URL scheme is targeted for this document and | |||
hence for location-based services that make use of the mapping | hence for location-based services that make use of the mapping | |||
protocol specified in this document. | protocol specified in this document. | |||
Interoperability considerations: | Interoperability considerations: | |||
None | None | |||
Security considerations: | Security considerations: | |||
See Section 16 | See Section 15 | |||
Relevant publications: | Relevant publications: | |||
This document provides the relevant context for this URL scheme. | This document provides the relevant context for this URL scheme. | |||
Contact: | Contact: | |||
Hannes Tschofenig, Hannes.Tschofenig@siemens.com | Hannes Tschofenig, Hannes.Tschofenig@siemens.com | |||
Author/Change controller: | Author/Change controller: | |||
The IESG <iesg@ietf.org> | The IESG <iesg@ietf.org> | |||
16. Security Considerations | 14.6. LoST Location Profile Registry | |||
This document seeks to create a registry of location profile names | ||||
for the LoST protocol. Profile names are XML tokens. This registry | ||||
will operate in accordance with RFC 2434 [2], Standards Action. | ||||
geodetic-2d: Defined in TBD | ||||
civic: Defined in TBD | ||||
15. Security Considerations | ||||
There are multiple threats to the overall system of which service | There are multiple threats to the overall system of which service | |||
mapping forms a part. An attacker that can obtain service contact | mapping forms a part. An attacker that can obtain service contact | |||
URIs can use those URIs to attempt to disrupt those services. An | URIs can use those URIs to attempt to disrupt those services. An | |||
attacker that can prevent the lookup of contact URIs can impair the | attacker that can prevent the lookup of contact URIs can impair the | |||
reachability of such services. An attacker that can eavesdrop on the | reachability of such services. An attacker that can eavesdrop on the | |||
communication requesting this lookup can surmise the existence of an | communication requesting this lookup can surmise the existence of an | |||
emergency and possibly its nature, and may be able to use this to | emergency and possibly its nature, and may be able to use this to | |||
launch a physical attack on the caller. | launch a physical attack on the caller. | |||
To avoid that an attacker can modify the query or its result, the | To avoid that an attacker can modify the query or its result, the use | |||
authors RECOMMEND the use of channel security, such as TLS, with | of channels security, such as TLS, is RECOMMENDED. | |||
LoST. | ||||
A more detailed description of threats and security requirements are | A more detailed description of threats and security requirements are | |||
provided in [4]. | provided in [17]. | |||
17. Acknowledgments | 16. Acknowledgments | |||
[Editor's Note: Names need to be added here. Forgot it...Sorry.] | [Editor's Note: Names need to be added here. Forgot it...Sorry.] | |||
18. Open Issues | 17. Open Issues | |||
Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ | Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ | |||
19. References | 18. References | |||
19.1. Normative References | ||||
[1] World Wide Web Consortium, "XML Schema Part 2: Datatypes", | ||||
W3C XML Schema, October 2000, | ||||
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>. | ||||
[2] World Wide Web Consortium, "XML Schema Part 1: Structures", | 18.1. Normative References | |||
W3C XML Schema, October 2000, | ||||
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>. | ||||
[3] 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. | |||
[4] Taylor, T., "Security Threats and Requirements for Emergency | [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |||
Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 | Considerations Section in RFCs", BCP 26, RFC 2434, | |||
(work in progress), July 2006. | October 1998. | |||
[5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency | [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., | |||
Context Resolution with Internet Technologies", | Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- | |||
draft-ietf-ecrit-requirements-12 (work in progress), | HTTP/1.1", RFC 2616, June 1999. | |||
August 2006. | ||||
[6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", | [4] Petke, R. and I. King, "Registration Procedures for URL Scheme | |||
draft-ietf-ecrit-service-urn-05 (work in progress), | Names", BCP 35, RFC 2717, November 1999. | |||
August 2006. | ||||
[7] Mealling, M., "The IETF XML Registry", | [5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | |||
draft-mealling-iana-xmlns-registry-05 (work in progress), | ||||
June 2003. | ||||
[8] Petke, R. and I. King, "Registration Procedures for URL Scheme | [6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", | |||
Names", BCP 35, RFC 2717, November 1999. | RFC 3023, January 2001. | |||
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, | Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, | |||
January 2005. | January 2005. | |||
[10] OpenGIS, "Open Geography Markup Language (GML) Implementation | [8] Peterson, J., "A Presence-based GEOPRIV Location Object | |||
Specification", OGC OGC 02-023r4, January 2003. | ||||
[11] Peterson, J., "A Presence-based GEOPRIV Location Object | ||||
Format", RFC 4119, December 2005. | Format", RFC 4119, December 2005. | |||
[12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", | [9] Freed, N. and J. Klensin, "Media Type Specifications and | |||
RFC 3023, January 2001. | ||||
[13] 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. | |||
[14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., | [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", | |||
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- | draft-ietf-ecrit-service-urn-05 (work in progress), | |||
HTTP/1.1", RFC 2616, June 1999. | August 2006. | |||
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. | ||||
[16] Thomson, M. and J. Winterbottom, "Revised Civic Location Format | [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format | |||
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-02 (work in | for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in | |||
progress), April 2006. | progress), September 2006. | |||
[17] Daigle, L., "Domain-based Application Service Location Using | [12] Daigle, L., "Domain-based Application Service Location Using | |||
URIs and the Dynamic Delegation Discovery Service (DDDS)", | URIs and the Dynamic Delegation Discovery Service (DDDS)", | |||
draft-daigle-unaptr-00 (work in progress), June 2006. | draft-daigle-unaptr-00 (work in progress), June 2006. | |||
19.2. Informative References | [13] OpenGIS, "Open Geography Markup Language (GML) Implementation | |||
Specification", OGC OGC 02-023r4, January 2003. | ||||
[18] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, | 18.2. Informative References | |||
December 2004. | ||||
[19] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 | [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., | |||
and DHCPv6) Option for Civic Addresses Configuration | Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: | |||
Information", draft-ietf-geopriv-dhcp-civil-09 (work in | Session Initiation Protocol", RFC 3261, June 2002. | |||
progress), January 2006. | ||||
[20] Schulzrinne, H., "Location-to-URL Mapping Architecture and | [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence | |||
Framework", draft-ietf-ecrit-mapping-arch-00 (work in | Protocol (XMPP): Instant Messaging and Presence", RFC 3921, | |||
progress), August 2006. | October 2004. | |||
[21] Rosen, B. and J. Polk, "Best Current Practice for | [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, | |||
Communications Services in support of Emergency Calling", | December 2004. | |||
draft-rosen-sos-phonebcp-01 (work in progress), June 2006. | ||||
[22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., | [17] Taylor, T., "Security Threats and Requirements for Emergency | |||
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: | Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 | |||
Session Initiation Protocol", RFC 3261, June 2002. | (work in progress), July 2006. | |||
[23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A | [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency | |||
Methodology for Network Address Translator (NAT) Traversal for | Context Resolution with Internet Technologies", | |||
Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in | draft-ietf-ecrit-requirements-12 (work in progress), | |||
August 2006. | ||||
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and | ||||
Framework", draft-ietf-ecrit-mapping-arch-00 (work in | ||||
progress), August 2006. | progress), August 2006. | |||
[24] Daigle, L. and A. Newton, "Domain-Based Application Service | [20] Rosen, B. and J. Polk, "Best Current Practice for | |||
Location Using SRV RRs and the Dynamic Delegation Discovery | Communications Services in support of Emergency Calling", | |||
Service (DDDS)", RFC 3958, January 2005. | draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006. | |||
Appendix A. Non-Normative RELAX NG Schema in XML Syntax | Appendix A. Non-Normative RELAX NG Schema in XML Syntax | |||
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<grammar ns="urn:ietf:params:xml:ns:lost1" | <grammar ns="urn:ietf:params:xml:ns:lost1" | |||
xmlns="http://relaxng.org/ns/structure/1.0" | xmlns="http://relaxng.org/ns/structure/1.0" | |||
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" | xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" | |||
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> | datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> | |||
<start> | <start> | |||
<a:documentation> | <a:documentation> | |||
Location-to-Service Translation Protocol (LoST) | Location-to-Service Translation Protocol (LoST) | |||
A LoST XML instance has three "root" types: | A LoST XML instance has three request types, each with | |||
the findServiceByLocation query, the listServices query, | a cooresponding response type: find service, list services, | |||
and the response to these queries. | and get service boundary. | |||
</a:documentation> | </a:documentation> | |||
<choice> | <choice> | |||
<ref name="findServiceByLocation" /> | <ref name="findService" /> | |||
<ref name="listServices" /> | <ref name="listServices" /> | |||
<ref name="response" /> | <ref name="getServiceBoundary" /> | |||
<ref name="findServiceResponse" /> | ||||
<ref name="listServicesResponse" /> | ||||
<ref name="getServiceBoundaryResponse" /> | ||||
</choice> | </choice> | |||
</start> | </start> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
The queries. | The queries. | |||
</a:documentation> | </a:documentation> | |||
<define name="findServiceByLocation"> | <define name="findService"> | |||
<element name="findServiceByLocation"> | <element name="findService"> | |||
<ref name="query" /> | <ref name="query" /> | |||
<optional> | <optional> | |||
<attribute name="validate"> | <attribute name="include"> | |||
<data type="boolean" /> | <list> | |||
<a:defaultValue>false</a:defaultValue> | <zeroOrMore> | |||
<choice> | ||||
<value>uri</value> | ||||
<value>serviceNumber</value> | ||||
<value>displayName</value> | ||||
<value>service</value> | ||||
<value>valid</value> | ||||
<value>invalid</value> | ||||
<value>unchecked</value> | ||||
<value>serviceBoundary</value> | ||||
<value>serviceBoundaryReference</value> | ||||
</choice> | ||||
</zeroOrMore> | ||||
</list> | ||||
<a:defaultValue>uri serviceNumber</a:defaultValue> | ||||
</attribute> | </attribute> | |||
</optional> | </optional> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="listServices"> | <define name="listServices"> | |||
<element name="listServices"> | <element name="listServices"> | |||
<ref name="query" /> | <ref name="query" /> | |||
</element> | </element> | |||
</define> | </define> | |||
<define name="getServiceBoundary"> | ||||
<element name="getServiceBoundary"> | ||||
<ref name="serviceBoundaryKey" /> | ||||
<ref name="extensionPoint" /> | ||||
</element> | ||||
</define> | ||||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
The response. | The responses. | |||
</a:documentation> | </a:documentation> | |||
<define name="response"> | <define name="findServiceResponse"> | |||
<element name="response"> | <element name="findServiceResponse "> | |||
<ref name="via" /> | ||||
<choice> | ||||
<group> | ||||
<optional> | <optional> | |||
<ref name="locationProfileError"/> | ||||
</optional> | ||||
<optional> | ||||
<ref name="serviceSubstitution"/> | ||||
</optional> | ||||
<ref name="serviceResult" /> | ||||
</group> | ||||
<ref name="badRequest"/> | ||||
<ref name="internalError"/> | ||||
<ref name="forbidden"/> | ||||
<ref name="notFound"/> | ||||
<ref name="serviceNotImplemented"/> | ||||
<ref name="serverTimeout"/> | ||||
<ref name="serverError"/> | ||||
<ref name="movedPermenantly"/> | ||||
<ref name="movedTemporarily"/> | ||||
<ref name="iterativeSearchExhausted"/> | ||||
</choice> | ||||
<ref name="extensionPoint" /> | ||||
</element> | ||||
</define> | ||||
<define name="listServicesResponse"> | ||||
<element name="listServicesResponse"> | ||||
<ref name="via" /> | ||||
<choice> | <choice> | |||
<a:documentation> | <group> | |||
2xx responses. | <optional> | |||
</a:documentation> | <ref name="locationProfileError"/> | |||
<ref name="result" /> | </optional> | |||
<element name="serviceList"> | <element name="serviceList"> | |||
<list> | <list> | |||
<zeroOrMore> | <zeroOrMore> | |||
<data type="anyURI" /> | <data type="anyURI" /> | |||
</zeroOrMore> | </zeroOrMore> | |||
</list> | </list> | |||
<ref name="status" /> | ||||
</element> | </element> | |||
</group> | ||||
</choice> | </choice> | |||
</optional> | <ref name="extensionPoint" /> | |||
<optional> | </element> | |||
<a:documentation> | </define> | |||
3xx, 4xx, and 4xx responses. | ||||
</a:documentation> | <define name="getServiceBoundaryResponse"> | |||
<element name="getServiceBoundaryResponse"> | ||||
<choice> | <choice> | |||
<ref name="error" /> | <group> | |||
<ref name="redirect" /> | <ref name="serviceBoundary"/> | |||
<ref name="failure" /> | </group> | |||
<ref name="badRequest"/> | ||||
<ref name="internalError"/> | ||||
<ref name="forbidden"/> | ||||
<ref name="notFound"/> | ||||
</choice> | </choice> | |||
</optional> | ||||
<ref name="extensionPoint" /> | <ref name="extensionPoint" /> | |||
</element> | </element> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Query pattern. | A pattern common to some of the queries. | |||
</a:documentation> | </a:documentation> | |||
<define name="query"> | <define name="query"> | |||
<element name="locationInfo"> | <oneOrMore> | |||
<zeroOrMore> | <element name="location"> | |||
<ref name="anyElement"/> | <ref name="locationInformation" /> | |||
</zeroOrMore> | ||||
</element> | </element> | |||
</oneOrMore> | ||||
<optional> | ||||
<element name="service"> | <element name="service"> | |||
<data type="anyURI"/> | <data type="anyURI"/> | |||
</element> | </element> | |||
</optional> | ||||
<ref name="extensionPoint" /> | <ref name="extensionPoint" /> | |||
<optional> | <optional> | |||
<attribute name="operation"> | <attribute name="recursive"> | |||
<a:defaultValue>recursive</a:defaultValue> | <data type="boolean" /> | |||
<a:defaultValue>true</a:defaultValue> | ||||
</attribute> | </attribute> | |||
</optional> | </optional> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
A result. | Location Information | |||
</a:documentation> | </a:documentation> | |||
<define name="result"> | <define name="locationInformation"> | |||
<oneOrMore> | ||||
<ref name="extensionPoint"/> | ||||
</oneOrMore> | ||||
<attribute name="profile"> | ||||
<data type="anyURI" /> | ||||
</attribute> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | <a:documentation> | |||
2xx response. | Service Boundary | |||
</a:documentation> | </a:documentation> | |||
<element name="result"> | <define name="serviceBoundary"> | |||
<oneOrMore> | ||||
<element name="serviceBoundary"> | ||||
<ref name="locationInformation" /> | ||||
</element> | ||||
</oneOrMore> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | ||||
Service Boundary Key | ||||
</a:documentation> | ||||
<define name="serviceBoundaryKey"> | ||||
<attribute name="key"> | ||||
<data type="string"> | ||||
<param name="pattern">[a-zA-Z0-9/+=]+</param> | ||||
</data> | ||||
</attribute> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | ||||
Via - list of places through which information flowed | ||||
</a:documentation> | ||||
<define name="via"> | ||||
<zeroOrMore> | ||||
<element name="via"> | ||||
<data type="anyURI"/> | ||||
</element> | ||||
</zeroOrMore> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | ||||
Time-to-live pattern | ||||
</a:documentation> | ||||
<define name="timeToLive"> | ||||
<attribute name="timeToLive"> | ||||
<data type="positiveInteger"/> | ||||
</attribute> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | ||||
A QName list | ||||
</a:documentation> | ||||
<define name="qnameList"> | ||||
<list> | ||||
<zeroOrMore> | ||||
<data type="QName"/> | ||||
</zeroOrMore> | ||||
</list> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | ||||
A location-to-service result. | ||||
</a:documentation> | ||||
<define name="serviceResult"> | ||||
<optional> | <optional> | |||
<element name="displayName"> | <element name="displayName"> | |||
<data type="string"/> | <data type="string"/> | |||
<attribute name="xml:lang"> | <attribute name="xml:lang"> | |||
<data type="language" /> | <data type="language" /> | |||
</attribute> | </attribute> | |||
</element> | </element> | |||
</optional> | </optional> | |||
<optional> | ||||
<element name="service"> | <element name="service"> | |||
<data type="anyURI"/> | <data type="anyURI"/> | |||
</element> | </element> | |||
<optional> | ||||
<element name="serviceBoundary"> | ||||
<choice> | ||||
<group> | ||||
<ref name="civicLocation" /> | ||||
<optional> | ||||
<ref name="polygon" /> | ||||
</optional> | </optional> | |||
</group> | ||||
<group> | ||||
<optional> | <optional> | |||
<ref name="civicLocation" /> | <choice> | |||
</optional> | <ref name="serviceBoundary"/> | |||
<ref name="polygon" /> | <element name="serviceBoundaryReference"> | |||
</group> | <ref name="serviceBoundaryKey"/> | |||
</choice> | ||||
</element> | </element> | |||
</choice> | ||||
</optional> | </optional> | |||
<oneOrMore> | <zeroOrMore> | |||
<element name="uri"> | <element name="uri"> | |||
<data type="anyURI"/> | <data type="anyURI"/> | |||
</element> | </element> | |||
</oneOrMore> | </zeroOrMore> | |||
<optional> | <optional> | |||
<element name="serviceNumber"> | <element name="serviceNumber"> | |||
<data type="string"> | <data type="string"> | |||
<param name="pattern">[0-9]+</param> | <param name="pattern">[0-9]+</param> | |||
</data> | </data> | |||
</element> | </element> | |||
</optional> | </optional> | |||
<optional> | <optional> | |||
<element name="validation"> | <element name="valid"> | |||
<list> | <ref name="qnameList" /> | |||
<zeroOrMore> | ||||
<data type="QName"/> | ||||
</zeroOrMore> | ||||
</list> | ||||
</element> | </element> | |||
</optional> | </optional> | |||
<ref name="extensionPoint" /> | <optional> | |||
<attribute name="timeToLive"> | <element name="invalid"> | |||
<data type="positiveInteger"/> | <ref name="qnameList" /> | |||
</attribute> | ||||
<ref name="status" /> | ||||
</element> | </element> | |||
</optional> | ||||
<optional> | ||||
<element name="unchecked"> | ||||
<ref name="qnameList" /> | ||||
</element> | ||||
</optional> | ||||
<ref name="extensionPoint"/> | ||||
<ref name="timeToLive"/> | ||||
<ref name="message"/> | ||||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Non-result responses. | Basic Errors | |||
</a:documentation> | </a:documentation> | |||
<define name="error"> | <define name="error"> | |||
<a:documentation> | <a:documentation> | |||
5xx response. | Error pattern. | |||
</a:documentation> | </a:documentation> | |||
<element name="error"> | <ref name="message"/> | |||
<ref name="status"/> | ||||
<ref name="extensionPoint" /> | <ref name="extensionPoint" /> | |||
</define> | ||||
<define name="badRequest"> | ||||
<element name="badRequest"> | ||||
<ref name="error"/> | ||||
</element> | </element> | |||
</define> | </define> | |||
<define name="redirect"> | <define name="internalError"> | |||
<element name="internalError"> | ||||
<ref name="error"/> | ||||
</element> | ||||
</define> | ||||
<define name="serviceSubstitution"> | ||||
<element name="serviceSubstitution"> | ||||
<ref name="error"/> | ||||
</element> | ||||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | <a:documentation> | |||
3xx response. | Recursion Errors. | |||
</a:documentation> | </a:documentation> | |||
<element name="redirect"> | ||||
<ref name="status"/> | <define name="recursionError"> | |||
<attribute name="redirect"> | <a:documentation> | |||
Recursion error. | ||||
</a:documentation> | ||||
<optional> | ||||
<attribute name="failedReferral"> | ||||
<data type="anyURI"/> | <data type="anyURI"/> | |||
</attribute> | </attribute> | |||
<ref name="extensionPoint" /> | </optional> | |||
<optional> | ||||
<choice> | ||||
<ref name="findService" /> | ||||
<ref name="listServices" /> | ||||
<ref name="getServiceBoundary" /> | ||||
</choice> | ||||
</optional> | ||||
<ref name="error"/> | ||||
</define> | ||||
<define name="forbidden"> | ||||
<element name="forbidden"> | ||||
<ref name="recursionError"/> | ||||
</element> | </element> | |||
<ref name="timeToLive"/> | ||||
</define> | </define> | |||
<define name="failure"> | <define name="notFound"> | |||
<a:documentation> | <element name="notFound"> | |||
4xx response. | <ref name="recursionError"/> | |||
</a:documentation> | </element> | |||
<element name="failure"> | <ref name="timeToLive"/> | |||
<ref name="status"/> | </define> | |||
<define name="serviceNotImplemented"> | ||||
<element name="serviceNotImplemented"> | ||||
<ref name="recursionError"/> | ||||
</element> | ||||
<ref name="timeToLive"/> | ||||
</define> | ||||
<define name="serverTimeout"> | ||||
<element name="serverTimeout"> | ||||
<ref name="recursionError"/> | ||||
</element> | ||||
<ref name="timeToLive"/> | ||||
</define> | ||||
<define name="serverError"> | ||||
<element name="serverError"> | ||||
<ref name="recursionError"/> | ||||
</element> | ||||
<ref name="timeToLive"/> | ||||
</define> | ||||
<define name="locationProfileError"> | ||||
<element name="locationProfileError"> | ||||
<attribute name="unsupportedProfiles"> | ||||
<list> | ||||
<zeroOrMore> | <zeroOrMore> | |||
<element name="cause"> | <data type="anyURI"/> | |||
<attribute name="name"> | </zeroOrMore> | |||
<data type="QName"/> | </list> | |||
</attribute> | ||||
<attribute name="message"> | ||||
<data type="string"/> | ||||
</attribute> | </attribute> | |||
<attribute name="xml:lang"> | <ref name="recursionError"/> | |||
<data type="language"/> | </element> | |||
</define> | ||||
</div> | ||||
<div> | ||||
<a:documentation> | ||||
Redirects. | ||||
</a:documentation> | ||||
<define name="redirect"> | ||||
<a:documentation> | ||||
Redirect pattern | ||||
</a:documentation> | ||||
<attribute name="redirect"> | ||||
<data type="anyURI"/> | ||||
</attribute> | </attribute> | |||
<ref name="error"/> | ||||
</define> | ||||
<define name="movedPermenantly"> | ||||
<element name="movedPermanently"> | ||||
<ref name="redirect"/> | ||||
</element> | </element> | |||
</zeroOrMore> | </define> | |||
<ref name="extensionPoint" /> | ||||
<define name="movedTemporarily"> | ||||
<element name="movedTemporarily"> | ||||
<ref name="redirect"/> | ||||
</element> | </element> | |||
<ref name="timeToLive" /> | ||||
</define> | ||||
<define name="iterativeSearchExhausted"> | ||||
<element name="iterativeSearchExhausted"> | ||||
<ref name="redirect"/> | ||||
</element> | ||||
<ref name="timeToLive" /> | ||||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Status pattern. | Message pattern. | |||
</a:documentation> | </a:documentation> | |||
<define name="status"> | <define name="message"> | |||
<attribute name="status"> | ||||
<data type="positiveInteger"/> | ||||
</attribute> | ||||
<optional> | ||||
<attribute name="extendedStatus"> | ||||
<data type="positiveInteger"/> | ||||
</attribute> | ||||
</optional> | ||||
<optional> | <optional> | |||
<group> | <group> | |||
<attribute name="message"> | <attribute name="message"> | |||
<data type="string"/> | <data type="string"/> | |||
</attribute> | </attribute> | |||
<attribute name="xml:lang"> | <attribute name="xml:lang"> | |||
<data type="language"/> | <data type="language"/> | |||
</attribute> | </attribute> | |||
</group> | </group> | |||
</optional> | </optional> | |||
</define> | </define> | |||
</div> | </div> | |||
<div> | <div> | |||
<a:documentation> | <a:documentation> | |||
Patterns for inclusion of elements from schemas in | Patterns for inclusion of elements from schemas in | |||
other namespaces. | other namespaces. | |||
</a:documentation> | </a:documentation> | |||
<define name="anyElement"> | <define name="notLost"> | |||
<a:documentation> | <a:documentation> | |||
A wildcard pattern for including any | Any element not in the LoST namespace. | |||
element from any other namespace. | ||||
</a:documentation> | </a:documentation> | |||
<element> | <element> | |||
<anyName/> | <anyName> | |||
<except> | ||||
<nsName ns="urn:ietf:params:xml:ns:lost1"/> | ||||
<nsName/> | ||||
</except> | ||||
</anyName> | ||||
<ref name="anyElement"/> | ||||
</element> | ||||
</define> | ||||
<define name="anyElement"> | ||||
<a:documentation> | ||||
A wildcard pattern for including any element | ||||
from any other namespace. | ||||
</a:documentation> | ||||
<zeroOrMore> | <zeroOrMore> | |||
<choice> | <choice> | |||
<element> | ||||
<anyName/> | ||||
<ref name="anyElement"/> | ||||
</element> | ||||
<attribute> | <attribute> | |||
<anyName/> | <anyName/> | |||
</attribute> | </attribute> | |||
<text/> | <text/> | |||
<ref name="anyElement"/> | ||||
</choice> | </choice> | |||
</zeroOrMore> | </zeroOrMore> | |||
</element> | ||||
</define> | </define> | |||
<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="anyElement" /> | <ref name="notLost" /> | |||
</zeroOrMore> | </zeroOrMore> | |||
</define> | </define> | |||
<define name="civicAddress"> | <define name="point2d"> | |||
<a:documentation> | <a:documentation> | |||
A pattern to include the GEOPRIV civil location elements. | A 2D point from GML. | |||
</a:documentation> | </a:documentation> | |||
<element> | <element name="position" ns="http://www.opengis.net/gml"> | |||
<nsName ns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/> | <element name="Point"> | |||
<zeroOrMore> | <attribute name="srsName"> | |||
<choice> | <value>urn:ogc:def:crs:EPSG:4326</value> | |||
<attribute> | ||||
<anyName/> | ||||
</attribute> | </attribute> | |||
<element name="pos"> | ||||
<text/> | <text/> | |||
<ref name="anyElement"/> | ||||
</choice> | ||||
</zeroOrMore> | ||||
</element> | </element> | |||
</define> | </element> | |||
<define name="civicLocation"> | ||||
<a:documentation> | ||||
A definition of civic location from GEOPRIV. | ||||
</a:documentation> | ||||
<element name="civicLocation"> | ||||
<zeroOrMore> | ||||
<ref name="civicAddress"/> | ||||
</zeroOrMore> | ||||
<zeroOrMore> | ||||
<ref name="anyElement" /> | ||||
</zeroOrMore> | ||||
</element> | </element> | |||
</define> | </define> | |||
<define name="GML"> | <define name="linearRing"> | |||
<a:documentation> | <a:documentation> | |||
A pattern to include GML elements. | A Linear Ring from GML. | |||
</a:documentation> | </a:documentation> | |||
<element> | <element name="LinearRing" ns="http://www.opengis.net/gml"> | |||
<nsName ns="http://www.opengis.net/gml" /> | <element name="pos"> | |||
<zeroOrMore> | ||||
<choice> | ||||
<attribute> | ||||
<anyName/> | ||||
</attribute> | ||||
<text/> | <text/> | |||
<ref name="anyElement" /> | </element> | |||
</choice> | ||||
</zeroOrMore> | ||||
</element> | </element> | |||
</define> | </define> | |||
<define name="polygon"> | <define name="polygon"> | |||
<a:documentation> | ||||
A Polygon from GML. | ||||
</a:documentation> | ||||
<element name="Polygon" ns="http://www.opengis.net/gml"> | <element name="Polygon" ns="http://www.opengis.net/gml"> | |||
<zeroOrMore> | <attribute name="srsName"> | |||
<attribute> | <value>urn:ogc:def:crs:EPSG:4979</value> | |||
<anyName/> | ||||
</attribute> | </attribute> | |||
<element name="exterior"> | ||||
<ref name="linearRing"/> | ||||
</element> | ||||
<zeroOrMore> | ||||
<element name="interior"> | ||||
<ref name="linearRing"/> | ||||
</element> | ||||
</zeroOrMore> | </zeroOrMore> | |||
<ref name="GML"/> | ||||
</element> | </element> | |||
</define> | </define> | |||
</div> | </div> | |||
</grammar> | </grammar> | |||
Authors' Addresses | Authors' Addresses | |||
Ted Hardie | Ted Hardie | |||
Qualcomm, Inc. | Qualcomm, Inc. | |||
Email: hardie@qualcomm.com | Email: hardie@qualcomm.com | |||
End of changes. 312 change blocks. | ||||
1007 lines changed or deleted | 1450 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |