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&#557;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&#557;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&#557;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&#557;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/