< draft-ietf-ecrit-lost-04.txt   draft-ietf-ecrit-lost-05.txt >
ECRIT T. Hardie ECRIT T. Hardie
Internet-Draft Qualcomm, Inc. Internet-Draft Qualcomm, Inc.
Intended status: Standards Track A. Newton Intended status: Standards Track A. Newton
Expires: August 15, 2007 SunRocket Expires: September 5, 2007 SunRocket
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
H. Tschofenig H. Tschofenig
Siemens Networks GmbH & Co KG Siemens Networks GmbH & Co KG
February 11, 2007 March 4, 2007
LoST: A Location-to-Service Translation Protocol LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-04.txt draft-ietf-ecrit-lost-05.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 August 15, 2007. This Internet-Draft will expire on September 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes an XML-based protocol for mapping service This document describes an XML-based protocol for mapping service
identifiers and geodetic or civic location information to service identifiers and geodetic or civic location information to service
contact URIs. In particular, it can be used to determine the contact URIs. In particular, it can be used to determine the
location-appropriate PSAP for emergency services. location-appropriate PSAP for emergency services.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Requirements Notation . . . . . . . . . . . . 6 2. Terminology and Requirements Notation . . . . . . . . . . . . 6
3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7
4. LoST servers and Their Resolution . . . . . . . . . . . . . . 8 4. LoST servers and Their Resolution . . . . . . . . . . . . . . 9
5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 9 5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 10
5.1. Data source and version: The 'source', 'sourceId' and 5.1. The Data Source: 'source', 'sourceId' and
'version' Attributes . . . . . . . . . . . . . . . . . . . 9 'lastUpdated' Attributes . . . . . . . . . . . . . . . . . 10
5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9 5.2. Validity: The 'expires' Attribute . . . . . . . . . . . . 10
5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9 5.3. Describing the Service with the <displayName> Element . . 11
5.4. Describing the Service with the <displayName> Element . . 10 5.4. The Mapped Service: the <service> Element . . . . . . . . 11
5.5. The Mapped Service: the <service> Element . . . . . . . . 10 5.5. Defining the Service Region with the <serviceBoundary>
5.6. Defining the Service Region with the <serviceBoundary> Element . . . . . . . . . . . . . . . . . . . . . . . . . 11
Element . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.6. Service Boundaries by Reference: the
5.7. Service Boundaries by Reference: the <serviceBoundaryReference> Element . . . . . . . . . . . . 12
<serviceBoundaryReference> Element . . . . . . . . . . . . 11 5.7. The Service Number Element . . . . . . . . . . . . . . . . 13
5.8. The Service Number Element . . . . . . . . . . . . . . . . 11 5.8. Service URLs: the <uri> Element . . . . . . . . . . . . . 13
5.9. Service URLs: the <uri> Element . . . . . . . . . . . . . 12 6. Path of a Request: <path> Element . . . . . . . . . . . . . . 14
6. Path of Request: <path> Element . . . . . . . . . . . . . . . 13 7. Mapping a Location and Service to URLs: <findService> . . . . 15
7. Mapping a Location and Service to URLs: <findService> . . . . 14 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 15
7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 14 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 16
7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 15 7.3. Components of the <findService> Request . . . . . . . . . 18
7.3. Components of the <findService> Request . . . . . . . . . 17 7.3.1. The <location> Element . . . . . . . . . . . . . . . . 18
7.3.1. The <location> Element . . . . . . . . . . . . . . . . 17 7.3.2. Identifying the Service: The <service> Element . . . 19
7.3.2. Identifying the Service: The <service> Element . . . 18 7.3.3. Recursion and Iteration . . . . . . . . . . . . . . . 19
7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 18 7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 19
7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 18 7.3.5. Requesting Civic Location Validation . . . . . . . . . 19
7.3.5. Requesting Civic Location Validation . . . . . . . . . 18
7.4. Components of the Mapping Response 7.4. Components of the Mapping Response
<findServiceResponse> . . . . . . . . . . . . . . . . . . 20 <findServiceResponse> . . . . . . . . . . . . . . . . . . 21
7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 20 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 21
7.4.2. Civic Address Validation: the 7.4.2. Civic Address Validation: the
<locationValidation> Element . . . . . . . . . . . . . 21 <locationValidation> Element . . . . . . . . . . . . . 22
8. Retrieving the Service Boundary via <getServiceBoundary> . . . 22 8. Retrieving the Service Boundary via <getServiceBoundary> . . . 23
9. List Services: <listServices> . . . . . . . . . . . . . . . . 25 9. List Services: <listServices> . . . . . . . . . . . . . . . . 26
10. List Services By Location: <listServicesByLocation> . . . . . 26 10. List Services By Location: <listServicesByLocation> . . . . . 27
11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 28 11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 29 11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 30
11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 32 11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 33
11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 33 11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 34
12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 34 12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 35
12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 34 12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 35 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 36 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 37
13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 37 13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 38
14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 38 14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 39
15. Internationalization Considerations . . . . . . . . . . . . . 45 15. Internationalization Considerations . . . . . . . . . . . . . 46
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 46 16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 47
16.2. Content-type registration for 'application/lost+xml' . . . 46 16.2. Content-type registration for 'application/lost+xml' . . . 47
16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 48 16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 49
16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 48 16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 49
16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 49 16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 50
17. Security Considerations . . . . . . . . . . . . . . . . . . . 50 17. Security Considerations . . . . . . . . . . . . . . . . . . . 51
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 53 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 54
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
20.1. Normative References . . . . . . . . . . . . . . . . . . . 54 20.1. Normative References . . . . . . . . . . . . . . . . . . . 55
20.2. Informative References . . . . . . . . . . . . . . . . . . 55 20.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . . . . 71 Intellectual Property and Copyright Statements . . . . . . . . . . 71
1. Introduction 1. Introduction
Numerous techniques have been specified for the discovery of servers
for a particular service, including NAPTR records, SVRLOC and similar
protocols. However, there are an important class of services where
the specific service instance that is to be connected to depends on
the identity of the service and the location of the entity that needs
to reach it. An example of this is emergency telecommunications
services, where the service instance is a Public Safety Answering
Point (PSAP) that has jurisdiction over the location of the user
making the call. Here, the desired PSAP isn't necessarily the one
that is topologically or even line-of-sight closest to the caller;
rather, it is the one that serves the callers location based on
geopolitical boundaries. For this reason, the selected service
instance is a function of location and the desired service.
This document describes a protocol for mapping a service identifier This document describes a protocol for mapping a service identifier
[10] and location information compatible with PIDF-LO [7], namely [9] and location information compatible with PIDF-LO [6], namely
revised civic location information [11] and GML [13]) to one or more revised civic location information [10] and GML [12]) to one or more
service URL. Example service URL schemes include sip [14], xmpp service URL. Example service URL schemes include sip [14], xmpp
[15], and tel [16]. While the initial focus is on providing mapping [15], and tel [16]. While the initial focus is on providing mapping
functions for emergency services, it is likely that the protocol is functions for emergency services, it is likely that the protocol is
applicable to any service URN. For example, in the United States, applicable to any service URN. For example, in the United States,
the "2-1-1" and "3-1-1" service numbers follow a similar location-to- the "2-1-1" and "3-1-1" service numbers follow a similar location-to-
service behavior as emergency services. service behavior as emergency services.
This document names this protocol "LoST", for Location-to-Service This document names this protocol "LoST", for Location-to-Service
Translation. LoST Satisfies the requirements [18] for mapping Translation. LoST Satisfies the requirements [18] for mapping
protocols. LoST provides a number of operations, centered around protocols. LoST provides a number of operations, centered around
skipping to change at page 4, line 31 skipping to change at page 4, line 45
information. LoST mapping queries can contain either civic or information. LoST mapping queries can contain either civic or
geodetic location information. For civic addresses, LoST can geodetic location information. For civic addresses, LoST can
indicate which parts of the civic address are known to be valid or indicate which parts of the civic address are known to be valid or
invalid, thus providing address validation (see Section 3.5 of [18] invalid, thus providing address validation (see Section 3.5 of [18]
for a description of validation). LoST indicates errors in the for a description of validation). LoST indicates errors in the
location data to facilitate debugging and proper user feedback, but location data to facilitate debugging and proper user feedback, but
also provides best-effort answers. also provides best-effort answers.
LoST queries can be resolved recursively or iteratively. To minimize LoST queries can be resolved recursively or iteratively. To minimize
round trips and to provide robustness against network failures, LoST round trips and to provide robustness against network failures, LoST
caches individual mappings and indicates the region for which the supports caching of individual mappings and indicates the region for
same answer would be returned ("service region"). which the same answer would be returned ("service region").
As defined in this document, LoST messages are carried in HTTP and As defined in this document, LoST messages are carried in HTTP and
HTTPS protocol exchanges, facilitating use of TLS for protecting the HTTPS protocol exchanges, facilitating use of TLS for protecting the
integrity and confidentiality of requests and responses. Later integrity and confidentiality of requests and responses.
documents may describe how LoST messages could be carried over other
transports.
This document focuses on the description of the protocol between the This document focuses on the description of the protocol between the
mapping client and the mapping server. The relationship between mapping client and the mapping server. Other functions, such as
other functions, such as discovery of mapping servers, data discovery of mapping servers, data replication and the overall
replication and the overall mapping server architecture are described mapping server architecture are described in a separate document
in a separate document [19]. [19].
The query message carries location information and a service The query message carries location information and a service
identifier encoded as a Uniform Resource Name (URN) (see [10]) from identifier encoded as a Uniform Resource Name (URN) (see [9]) from
the LoST client to the LoST server. The LoST server uses its the LoST client to the LoST server. The LoST server uses its
database to map the input values to one or more Uniform Resource database to map the input values to one or more Uniform Resource
Identifiers (URI) and returns those URIs along with optional Identifiers (URI) and returns those URIs along with optional
information, such as hints about the service boundary, in a response information, such as hints about the service boundary, in a response
message to the LoST client. If the server cannot resolve the query message to the LoST client. If the server cannot resolve the query
itself, it may in turn query another server or return the address of itself, it may in turn query another server or return the address of
another LoST server, identified by a LoST server name. In addition another LoST server, identified by a LoST server name. In addition
to the mapping function described in Section 7, the protocol also to the mapping function described in Section 7, the protocol also
allows to retrieve the service boundary (see Section 8) and to list allows to retrieve the service boundary (see Section 8) and to list
the services available for a particular location (see Section 10) or the services available for a particular location (see Section 10) or
supported by a particular server (see Section 9). supported by a particular server (see Section 9).
2. Terminology and Requirements Notation 2. Terminology and Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
This document furthermore uses the terminology defined in [18]. This document uses the following terms:
Mapping:
Mapping is a process that takes a location and a service
identifier as inputs and returns one or more URIs that point to a
host providing that service or acting as an intermediary to
establish communication with the serving entity. This definition
is a generalization of the term "mapping" as used in [18], because
of the potential for LoST to be used for non-emergency services.
LoST Client and Server:
"LoST client" is the role played by an entity that sends LoST
query messages and receives LoST response messages. "LoST server"
is the role played by an entity that receives LoST query messages
and sends LoST response messages. In recursive operation, the
same entity may play both roles. This document also uses the term
"authoritative server" to designate an entity that acts in the
LoST server role only and successfully resolves the input location
and service identifier to a URI or set of URIs.
Service Boundary:
A service boundary is the boundary or set of boundaries of a
geographic region, respectively set of geographic regions, within
which all locations will map to the same URI or set of URIs for a
given service.
Validation:
The term "validation" as used in this document is a concrete
realization of the term "location validation" as defined in
Section 3.5 of [18].
Additional emergency service terminology can be found in [18].
3. Overview of Protocol Usage 3. Overview of Protocol Usage
The client may perform the mapping at any time. Among the common The LoST protocol supports the following type of queries and
triggers for mapping requests are: responses:
<findService> and <findServiceResponse>
This message pattern allows to perform retrieve contact URIs based
on location information together with a service identifier. The
same query type may also ask for location validation and for
service numbers, either integrated into mapping request or
separately. The details can be found in Section 7 and
Section 7.4.
<getServiceBoundary> and <getServiceBoundaryResponse>
This message pattern allows query for a service boundary. The
details can be found in Section 8.
<listServices> and <listServicesResponse>
This message pattern enables a LoST client to ask a LoST server
for the services it supports. The details can be found in
Section 9.
<listServicesByLocation> and <listServicesByLocationResponse>
This message pattern provides the LoST client with the services
that are available for a specific location region. The details
can be found in Section 10.
LoST clients may initiate any of the above queries at any time.
Among the common triggers are:
1. When the client initially starts up or attaches to a network. 1. When the client initially starts up or attaches to a network.
2. When the client detects that its location has changed 2. When the client detects that its location has changed
sufficiently that it is outside the bounds of the service region sufficiently that it is outside the bounds of the service region.
returned in an earlier LoST query.
3. When cached mapping information has expired. 3. An incoming message at a SIP proxy in a location-based routing
scenario that requires a routing decision to be made.
4. When invoking a particular service. At that time, a client may 4. When cached mapping information has expired.
5. When invoking a particular service. At that time, a client may
omit requests for service boundaries or other auxiliary omit requests for service boundaries or other auxiliary
information. information.
A service-specific Best Current Practice (BCP) document, such as A service-specific Best Current Practice (BCP) document, such as
[20], governs whether a client is expected to invoke the mapping [20], governs whether a client is expected to invoke the mapping
service just before needing the service or whether to rely on cached service just before needing the service or whether to rely on cached
answers. Cache entries expire at their expiration time (see answers. Cache entries expire at their expiration time (see
Section 5.3), or they become invalid if the caller's device moves Section 5.2), or they become invalid if the caller's device moves
beyond the boundaries of the service region. beyond the boundaries of the service region.
4. LoST servers and Their Resolution 4. LoST servers and Their Resolution
A LoST server may be discovered using a U-NAPTR/DDDS [12] application LoST servers are identified by U-NAPTR/DDDS [11] application unique
unique string (AUS), in the form of a DNS name. strings, in the form of a DNS name.
An example is 'lostserver.example.com' An example is 'lostserver.example.com'
Clients need to use the U-NAPTR [12] specification described below to Clients need to use the U-NAPTR [11] specification described below to
obtain a URI (indicating host and protocol) for the applicable LoST obtain a URI (indicating host and protocol) for the applicable LoST
service. In this document, only the HTTP and HTTPS URL schemes are service. In this document, only the HTTP and HTTPS URL schemes are
defined. Note that the HTTP URL can be any valid HTTP URL, including defined. Note that the HTTP URL can be any valid HTTP URL, including
those containing path elements. those containing path elements.
The following two DNS entries show the U-NAPTR resolution for the AUS The following two DNS entries show the U-NAPTR resolution for
"example.com" to the HTTPS URL https://lostserv.example.com/secure or "example.com" to the HTTPS URL https://lostserv.example.com/secure or
the HTTP URL http://lostserver.example.com, with the former being the HTTP URL http://lostserver.example.com, with the former being
preferred. preferred.
example.com. example.com.
IN NAPTR 100 10 "u" "LoST:https" IN NAPTR 100 10 "u" "LoST:https"
"!*.!https://lostserver.example.com/secure!" "" "!.*!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http" IN NAPTR 200 10 "u" "LoST:http"
"!*.!http://lostserver.example.com!" "" "!.*!http://lostserver.example.com!" ""
Clients learn the LoST server's AUS by means beyond the scope of this Clients learn the LoST server's host name by means beyond the scope
specification, such as SIP configuration and DHCP. of this specification, such as SIP configuration and DHCP.
5. The <mapping> Element 5. The <mapping> Element
The <mapping> element is the core data element in LoST, describing a The <mapping> element is the core data element in LoST, describing a
service region and the associated service URLs. Its attributes and service region and the associated service URLs. Its attributes and
elements are described in subsections below. elements are described in subsections below.
5.1. Data source and version: The 'source', 'sourceId' and 'version' 5.1. The Data Source: 'source', 'sourceId' and 'lastUpdated' Attributes
Attributes
The 'source', 'sourceId' and 'version' attributes uniquely identify a The 'source', the 'sourceId' and the 'lastUpdated' attributes
particular mapping record. They are created by the authoritative uniquely identify a particular mapping record. They are created by
source for a mapping and never modified when a mapping is served from the authoritative source for a mapping and never modified when a
a cache. All three attributes are REQUIRED for all <mapping> mapping is served from a cache. All three attributes are REQUIRED
elements. A receiver can replace a mapping with another one having for all <mapping> elements. A receiver can replace a mapping with
the same 'source' and 'sourceId' and a higher version number. another one having the same 'source' and 'sourceId' and a more recent
datum in 'lastUpdated'.
The 'source' attribute contains a LoST application unique string The 'source' attribute contains a LoST application unique string
identifying the authoritative generator of the mapping. See identifying the authoritative generator of the mapping. See
Section 4. Section 4.
The 'sourceId' attribute identifies a particular mapping and contains The 'sourceId' attribute identifies a particular mapping and contains
an opaque token that MUST be unique among all different mappings an opaque token that MUST be unique among all different mappings
maintained by the authoritative source for that particular service. maintained by the authoritative source for that particular service.
For example, a Universally Unique Identifier (UUID) is a suitable For example, a Universally Unique Identifier (UUID) is a suitable
format. format.
The 'version' attribute is a positive integer that is incremented for The 'lastUpdated' attribute describes when a specific instance of
each change in the mapping. The XML data type does not specify an mapping, identified by the combination of 'source' and 'sourceId',
upper bound for this attribute and thus, the value MUST NOT wrap was last changed. The contents of this attribute has the XML data
around. Thus, a higher version number refers to a more recent type dateTime in its timezoned form, using canonical UTC
mapping. A mapping maintains its sourceId value as long as it representation with the letter 'Z' as the timezone indicator.
remains logically the same, e.g., represents the same service
boundary or replaces an earlier service boundary.
5.2. Time of Last Update: The 'lastUpdated' Attribute
The 'lastUpdated' attribute describes when the mapping was last
changed. The contents of this attribute has the XML data type
dateTime in its timezoned form, using canonical UTC representation
with the letter 'Z' as the timezone indicator. The attribute is
REQUIRED.
5.3. Validity: The 'expires' Attribute 5.2. Validity: The 'expires' Attribute
The 'expires' attribute contains the absolute time at which the The 'expires' attribute contains the absolute time at which the
mapping becomes invalid. The contents of this attribute is a mapping becomes invalid. The contents of this attribute is a
timezoned XML type dateTime, in canonical representation. See timezoned XML type dateTime, in canonical representation. See
Section 3 regarding how this value is to be utilized with a cache. Section 3 regarding how this value is to be utilized with a cache.
The 'expires' attribute is REQUIRED to be included in the <mapping> The 'expires' attribute is REQUIRED to be included in the <mapping>
element. element.
Optionally, this attribute may contain the values of 'NO-CACHE' and
'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is
an indication that the mapping should not be cached. The value of
'NO-EXPIRATION' is an indication that the mapping does not expire.
On occasion, a server may be forced to return an expired mapping if On occasion, a server may be forced to return an expired mapping if
it cannot reach the authoritative server or the server fails to it cannot reach the authoritative server or the server fails to
return a usable answer. Clients and servers MAY cache the mapping so return a usable answer. Clients and servers MAY cache the mapping so
that they have at least some information available. Caching servers that they have at least some information available. Caching servers
that have such stale information SHOULD re-attempt the query each that have such stale information SHOULD re-attempt the query each
time a client requests a mapping. time a client requests a mapping. Since the expired mapping will be
returned to the client as a non-error/non-warning response it is the
responsibility of the client to check the 'expires' attribute
associated with mapping data returned in a LoST response to detemine
whether the mapping is fresh.
5.4. Describing the Service with the <displayName> Element 5.3. Describing the Service with the <displayName> Element
Zero or more <displayName> elements describe the service with a Zero or more <displayName> elements describe the service with a
string that is suitable for display to human users, each annotated string that is suitable for display to human users, each annotated
with the 'xml:lang' attribute that contains a language tag to aid in with the 'xml:lang' attribute that contains a language tag to aid in
the rendering of text. the rendering of text.
5.5. The Mapped Service: the <service> Element 5.4. The Mapped Service: the <service> Element
The <service> element identifies the service for which this mapping The <service> element identifies the service for which this mapping
applies. Two cases need to be distinguished when the LoST server applies. Two cases need to be distinguished when the LoST server
sets the <service> element in the response message: sets the <service> element in the response message:
1. If the requested service, identified by the service URN [10] in 1. If the requested service, identified by the service URN [9] in
the <service> element of the request, exists for the location the <service> element of the request, exists for the location
indicated, then the LoST server puts the service URN from the indicated, then the LoST server puts the service URN from the
request into the <service> element. request into the <service> element.
2. If, however, the requested service, identified by the service URN 2. If, however, the requested service, identified by the service URN
[10] in the <service> element in the request, does not exist for [9] in the <service> element in the request, does not exist for
the location indicated, the server can either return an the location indicated, the server can either return an
<serviceNotImplemented> (Section 12.1) error or can provide an <serviceNotImplemented> (Section 12.1) error or can provide an
alternate service that approximates the desired service for that alternate service that approximates the desired service for that
location. In the latter case, the server MUST include a location. In the latter case, the server MUST include a
<service> element with the alternative service URN. The choice <service> element with the alternative service URN. The choice
of service URN is left to local policy, but the alternate service of service URN is left to local policy, but the alternate service
should be able to satisfy the original service request. should be able to satisfy the original service request.
The <service> element is optional but may also be required if the The <service> element is optional but may also be required if the
mapping is to be digitally signed. mapping is to be digitally signed.
5.6. Defining the Service Region with the <serviceBoundary> Element 5.5. Defining the Service Region with the <serviceBoundary> Element
A response MAY indicate the region for which the service URL returned A response MAY indicate the region for which the service URL returned
would be the same as in the actual query, the so-called _service would be the same as in the actual query, the so-called _service
region_. The service region can be indicated by value or by region_. The service region can be indicated by value or by
reference (see Section 5.7). If a client moves outside the service reference (see Section 5.6). If a client moves outside the service
area and wishes to obtain current service data, it sends a new query area and wishes to obtain current service data, it sends a new query
with its current location. The service region is described by value with its current location. The service region is described by value
in one or more <serviceBoundary> elements, each formatted according in one or more <serviceBoundary> elements, each formatted according
to a different location profile, identified by the 'profile' atribute to a different location profile, identified by the 'profile' atribute
(see Section 11). The response MUST contain at least one service (see Section 11). If included in a response, the <serviceBoundary>
boundary using the same profile as the request. The client only element MUST contain at least one service boundary that uses the same
processes the first element that it can understand according to its profile as the request. The client only processes the first element
list of supported location profiles. Thus, elements with geospatial that it can understand according to its list of supported location
coordinates are alternative descriptions of the same service region, profiles. Thus, elements with geospatial coordinates are alternative
not additive geometries. descriptions of the same service region, not additive geometries.
A service boundary is requested by the client (using the
'serviceBoundary' attribute in the request with the value set to
"value").
A response MAY contain more than one <serviceBoundary> element with A response MAY contain more than one <serviceBoundary> element with
profile 'civic'. Each <serviceBoundary> element describes a set of profile 'civic'. Each <serviceBoundary> element describes a set of
civic addresses that fall within the service boundary, namely all civic addresses that fall within the service boundary, namely all
addresses that textually match the civic address elements provided, addresses that textually match the civic address elements provided,
regardless of the value of other address elements. A location falls regardless of the value of other address elements. A location falls
within the mapping's service boundary if it matches any of the within the mapping's service boundary if it matches any of the
<serviceBoundary> elements. <serviceBoundary> elements.
5.7. Service Boundaries by Reference: the <serviceBoundaryReference> 5.6. Service Boundaries by Reference: the <serviceBoundaryReference>
Element Element
Since geodetic service boundaries may contain thousands of points and Since geodetic service boundaries may contain thousands of points and
thus be quite large, clients may opt to conserve bandwidth and thus be quite large, clients may opt to conserve bandwidth and
request a reference to the service boundary instead of the value request a reference to the service boundary instead of the value
described in Section 5.6. The identifier of the service boundary is described in Section 5.5. The identifier of the service boundary is
returned as an attribute of the <serviceBoundaryReference> element, returned as an attribute of the <serviceBoundaryReference> element,
along with a LoST application unique string (see Section 4) along with a LoST application unique string (see Section 4)
identifying the server from where it can be retrieved. The actual identifying the server from where it can be retrieved. The actual
value of the service boundary is then retrieved with the value of the service boundary is then retrieved with the
getServiceBoundary (Section 8) request. getServiceBoundary (Section 8) request.
A reference to a service boundary is requested by the client (using
the 'serviceBoundary' attribute in the request with the value set to
"reference"). A LoST server may decide, based on local policy, to
return the service boundary per value or to omit the
<serviceBoundaryReference> element in the response.
The identifier is a random token with at least 128 bits of entropy The identifier is a random token with at least 128 bits of entropy
and can be assumed to be globally unique. It uniquely references a and can be assumed to be globally unique. It uniquely references a
particular boundary. If the boundary changes, a new identifier MUST particular boundary. If the boundary changes, a new identifier MUST
be chosen. Because of these properties, a client receiving a mapping be chosen. Because of these properties, a client receiving a mapping
response can simply check if it already has a copy of the boundary response can simply check if it already has a copy of the boundary
with that identifier. If so, it can skip checking with the server with that identifier. If so, it can skip checking with the server
whether the boundary has been updated. Since service boundaries are whether the boundary has been updated. Since service boundaries are
likely to remain unchanged for extended periods of time, possibly likely to remain unchanged for extended periods of time, possibly
exceeding the normal lifetime of the service URL, this approach exceeding the normal lifetime of the service URL, this approach
avoids unnecessarily refreshing the boundary information just because avoids unnecessarily refreshing the boundary information just because
the the remainder of the mapping has become invalid. the the remainder of the mapping has become invalid.
5.8. The Service Number Element 5.7. The Service Number Element
The service number is returned in the optional <serviceNumber> The service number is returned in the optional <serviceNumber>
element. It contains a string of digits, * and # that a user on a element. It contains a string of digits, * and # that a user on a
device with a 12-key dial pad could use to reach that particular device with a 12-key dial pad could use to reach that particular
service. service.
5.9. Service URLs: the <uri> Element 5.8. Service URLs: the <uri> Element
The response returns the service URLs in one or more <uri> elements. The response returns the service URLs in one or more <uri> elements.
The URLs MUST be absolute URLs. The ordering of the URLs has no The URLs MUST be absolute URLs. The ordering of the URLs has no
particular significance. Each URL scheme MUST only appear at most particular significance. Each URL scheme MUST only appear at most
once, but it is permissible to include both secured and regular once, but it is permissible to include both secured and regular
versions of a protocol, such as both 'http' and 'https' or 'sip' and versions of a protocol, such as both 'http' and 'https' or 'sip' and
'sips'. 'sips'.
6. Path of Request: <path> Element 6. Path of a Request: <path> Element
To prevent loops and to allow tracing of request and response paths, To prevent loops and to allow tracing of request and response paths,
all requests that allow recursion include a <path> element that all requests that allow recursion include a <path> element that
contains one or more <via> elements, each possessing an attribute contains one or more <via> elements, each possessing an attribute
containing a LoST application unique string (see Section 4). The containing a LoST application unique string (see Section 4). The
order of <via> elements corresponds to the order of LoST servers, order of <via> elements corresponds to the order of LoST servers,
i.e., the first <via> element identifies the server that first i.e., the first <via> element identifies the server that initially
received the request from the client. The authoritative server received the request from the client issuing the request. The <via>
copies the <path> element verbatim into the response. element is inserted logically on receipt of the request, so that
every server in a recursive query operation is included in the <path>
element.
The server that answers the request instead of forwarding it, such as
the authoritative server, copies the <path> element verbatim into the
response. The <path> element is not modified in responses as the
responses traverses the server chain back to the querying client.
If a query is answered iteratively, the querier includes all servers If a query is answered iteratively, the querier includes all servers
that it has already contacted. that it has already contacted.
The example in Figure 5 indicates that the answer was given to the The example in Figure 5 indicates that the answer was given to the
responding server by the LoST server at esgw.ueber-110.de.example, client by the LoST server at esgw.ueber-110.de.example, which got the
which got the answer from the LoST server at answer from the (authoritative) LoST server at
polizei.muenchen.de.example. polizei.muenchen.de.example.
7. Mapping a Location and Service to URLs: <findService> 7. Mapping a Location and Service to URLs: <findService>
7.1. Overview 7.1. Overview
The <findService> query constitutes the core of the LoST The <findService> query constitutes the core of the LoST
functionality, mapping civic or geodetic locations to URLs and functionality, mapping civic or geodetic locations to URLs and
associated data. After giving an example, we enumerate the elements associated data. After giving an example, we enumerate the elements
of the query and response. of the query and response.
skipping to change at page 14, line 44 skipping to change at page 15, line 44
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 2: A <findService> geodetic query Figure 2: A <findService> geodetic query
Given the query above, a server would respond with a service, and Given the query above, a server would respond with a service, and
information related to that service. In the example below, the information related to that service. In the example below, the
server has mapped the location given by the client for a police server has mapped the location given by the client for a police
service to the New York City Police Deparment, instructing the client service to the New York City Police Deparment, instructing the client
that it may contact them via the URIs "sip:sfpd@example.com" and that it may contact them via the URIs "sip:nypd@example.com" and
"xmpp:sfpd@example.com". The server has also given the client a "xmpp:nypd@example.com". The server has also given the client a
geodetic, two-dimensional boundary for this service. The mapping was geodetic, two-dimensional boundary for this service. The mapping was
last updated on November 1, 2006 and expires on January 1, 2007. If last updated on November 1, 2006 and expires on January 1, 2007. If
the client's location changes beyond the given service boundary or the client's location changes beyond the given service boundary or
the expiration time has been reached, it may want to requery for this the expiration time has been reached, it may want to requery for this
information, depending on the usage environment of LoST. information, depending on the usage environment of LoST.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"> xmlns:p2="http://www.opengis.net/gml">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example" source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" version="1"> sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">
<displayName xml:lang="en"> <displayName xml:lang="en">
San Francisco Police Department New York City Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <p2:exterior>
<p2:LinearRing> <p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing> </p2:LinearRing>
</p2:exterior> </p2:exterior>
</p2:Polygon> </p2:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:sfpd@example.com</uri> <uri>sip:nypd@example.com</uri>
<uri>xmpp:sfpd@example.com</uri> <uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<path> <path>
<via source="authoritative.example"/> <via source="authoritative.example"/>
<via source="resolver.example"/> <via source="resolver.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 3: A <findServiceResponse> geodetic answer Figure 3: A <findServiceResponse> geodetic answer
skipping to change at page 17, line 42 skipping to change at page 18, line 42
<via source="polizei.muenchen.de.example"/> <via source="polizei.muenchen.de.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 5: A <findServiceResponse> civic address answer Figure 5: A <findServiceResponse> civic address answer
7.3. Components of the <findService> Request 7.3. Components of the <findService> Request
The <findService> request includes attributes that govern whether the The <findService> request includes attributes that govern whether the
request is handled iteratively or recursively, whether location request is handled iteratively or recursively, whether location
validation is performed and which elements must be contained in the validation is performed and which elements may be contained in the
response. response.
7.3.1. The <location> Element 7.3.1. The <location> Element
The <findService> query communicates location information using one The <findService> query communicates location information using one
or more <location> elements, which MUST conform to a location profile or more <location> elements, which MUST conform to a location profile
(see Section 11). There MUST NOT be more than one location element (see Section 11). There MUST NOT be more than one location element
for each distinct location profile. The order of location objects is for each distinct location profile. The order of location objects is
significant; the server uses the first location object where it significant; the server uses the first location object where it
understands the location profile. understands the location profile.
7.3.2. Identifying the Service: The <service> Element 7.3.2. Identifying the Service: The <service> Element
The type of service desired is specified by the <service> element. The type of service desired is specified by the <service> element.
It contains service URNs from the registry established in [10]. It contains service URNs from the registry established in [9].
7.3.3. Recursion 7.3.3. Recursion and Iteration
LoST <findService> and <listServicesByLocation> queries can be LoST can operate in either recursive or iterative mode, on a request-
recursive, as indicated by the 'recursive' attribute. A value of by-request basis. In recursive mode, the LoST server initiates
"true" indicates a recursive query, with the default being "false" queries on behalf of the requester and returns the result to the
when the attribute is omitted. Regardless of the attribute, a server requester.
MAY always answer a query by providing a LoST application unique
string (see Section 4), i.e., indirection, however, it MUST NOT
recurse if the attribute is "false".
In recursive mode, the LoST server initiates queries on behalf of the In iterative mode, the server contacted returns a redirection
requester and returns the result to the requester, inserting a <via> response indicating the next server to be queried.
element to track the response chain. The <via> elements are appended
in responses in order of visit, i.e., the first <via> element For the queries defined in this document, only LoST <findService> and
contains the authoritative server and <via> elements below indicate <listServicesByLocation> queries can be recursive, as indicated by
servers that the response traversed on its way back to the original the 'recursive' attribute. A value of "true" indicates a recursive
querier. query, with the default being "false" when the attribute is omitted.
Regardless of the attribute, a server MAY always answer a query by
providing a LoST application unique string (see Section 4), i.e.,
indirection, however, it MUST NOT recurse if the attribute is
"false".
7.3.4. Service Boundary 7.3.4. Service Boundary
LoST <mapping> elements can describe the service boundary either by LoST <mapping> elements can describe the service boundary either by
value or by reference. Returning a service boundary reference is value or by reference. Returning a service boundary reference is
generally more space-efficient for geospatial (polygon) boundaries generally more space-efficient for geospatial (polygon) boundaries
and if the boundaries change rarely, but does incur an additional and if the boundaries change rarely, but does incur an additional
<getServiceBoundary> request. The querier can express a preference <getServiceBoundary> request. The querier can express a preference
for one or the other modality with the 'serviceBoundary' attribute in for one or the other modality with the 'serviceBoundary' attribute in
the <findService> request, but the server makes the final decision as the <findService> request, but the server makes the final decision as
to whether to return a reference or a value. Servers SHOULD NOT to whether to return a reference or a value.
return a by-value service boundaries if the querier requested a
reference.
7.3.5. Requesting Civic Location Validation 7.3.5. Requesting Civic Location Validation
Civic address validation is requested by setting the optional Civic address validation is requested by setting the optional
attribute 'validateLocation' to true. If the attribute is omitted, attribute 'validateLocation' to true. If the attribute is omitted,
it is assumed to be false. The response is described in it is assumed to be false. The response is described in
Section 7.4.2. The example in Figure 6 demonstrates address Section 7.4.2. The example in Figure 6 demonstrates address
validation, omitting the standard response elements. validation, omitting the standard response elements.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 21, line 9 skipping to change at page 22, line 9
Mapping responses consist of the <mapping> element (Section 5) Mapping responses consist of the <mapping> element (Section 5)
describing the mapping itself, possibly followed by warnings describing the mapping itself, possibly followed by warnings
(Section 12.2), location validation information (Section 7.4.2), and (Section 12.2), location validation information (Section 7.4.2), and
an indication of the path (Section 6) the response has taken. an indication of the path (Section 6) the response has taken.
7.4.2. Civic Address Validation: the <locationValidation> Element 7.4.2. Civic Address Validation: the <locationValidation> Element
A server can indicate in its response which civic address elements it A server can indicate in its response which civic address elements it
has recognized as valid, which ones it has ignored and which ones it has recognized as valid, which ones it has ignored and which ones it
has checked and found to be invalid. The server MUST include this has checked and found to be invalid. The server SHOULD include this
information if the 'validateLocation' attribute in the request was information if the 'validateLocation' attribute in the request was
true. Each element contains a list of tokens separated by white true but local policy at the server may allow this information to be
omitted. Each element contains a list of tokens separated by white
space, enumerating the civic location lables used in child elements space, enumerating the civic location lables used in child elements
of the <civicAddress> element. The <valid> element enumerates those of the <civicAddress> element. The <valid> element enumerates those
civic address elements that have been recognized as valid by the LoST civic address elements that have been recognized as valid by the LoST
server and that have been used to determine the mapping. The server and that have been used to determine the mapping. The
<unchecked> elements enumerates the civic address elements that the <unchecked> elements enumerates the civic address elements that the
server did not check and that were not used in determining the server did not check and that were not used in determining the
response. The <invalid> element enumerate civic address elements response. The <invalid> element enumerate civic address elements
that the server attempted to check, but that did not match the other that the server attempted to check, but that did not match the other
civic address elements found in the <valid> list. civic address elements found in the <valid> list.
skipping to change at page 22, line 7 skipping to change at page 23, line 7
the postal code or the city is considered valid. The mapping the postal code or the city is considered valid. The mapping
naturally corresponds to the valid elements. naturally corresponds to the valid elements.
The example (Figure 6) indicates that the tokens 'country', 'A1', The example (Figure 6) indicates that the tokens 'country', 'A1',
'A3', and 'A6' have been validated by the LoST server. The server '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 considered the postal code 81675 in the <PC> element as not valid for
this location. this location.
8. Retrieving the Service Boundary via <getServiceBoundary> 8. Retrieving the Service Boundary via <getServiceBoundary>
As discussed in Section 5.6, the <findServiceResponse> can return a As discussed in Section 5.5, the <findServiceResponse> can return a
globally unique identifier in the 'serviceBoundary' attribute that globally unique identifier in the 'serviceBoundary' attribute that
can be used to retrieve the service boundary, rather than returning can be used to retrieve the service boundary, rather than returning
the boundary by value. This is shown in the example in Figure 8. the boundary by value. This is shown in the example in Figure 8.
The client can then retrieve the boundary using the The client can then retrieve the boundary using the
<getServiceBoundary> request and obtains the boundary in the <getServiceBoundary> request and obtains the boundary in the
<getServiceBoundaryResponse>, illustrated in the example in <getServiceBoundaryResponse>, illustrated in the example in
Figure 10. The client issues the request to the server identified in Figure 10. The client issues the request to the server identified in
the 'server' attribute of the <serviceBoundaryReference> element. the 'server' attribute of the <serviceBoundaryReference> element.
These requests are always directed to the authoritative server and do These requests are always directed to the authoritative server and do
not recurse. not recurse.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findService <findService
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" xmlns:p2="http://www.opengis.net/gml"
recursive="true" recursive="true"
serviceBoundary="reference"> serviceBoundary="reference">
<location profile="geodetic-2d"> <location profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos> <p2:pos>37.775 -122.422</p2:pos>
</p2:Point> </p2:Point>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 8: <findService> request and response with service boundary Figure 8: <findService> request and response with service boundary
reference reference
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"> xmlns:p2="http://www.opengis.net/gml">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example" source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" sourceId="7e3f40b098c711dbb6060800200c9a66"
version="1"> version="1">
<displayName xml:lang="en"> <displayName xml:lang="en">
San Francisco Police Department New York City Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundaryReference <serviceBoundaryReference
source="authoritative.example" source="authoritative.example"
key="7214148E0433AFE2FA2D48003D31172E" /> key="7214148E0433AFE2FA2D48003D31172E" />
<uri>sip:sfpd@example.com</uri> <uri>sip:nypd@example.com</uri>
<uri>xmpp:sfpd@example.com</uri> <uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<path> <path>
<via source="authoritative.example"/> <via source="authoritative.example"/>
<via source="resolver.example"/> <via source="resolver.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 9: <findServiceResponse> message with service boundary Figure 9: <findServiceResponse> message with service boundary
reference reference
skipping to change at page 24, line 10 skipping to change at page 25, line 10
The <getServiceBoundary> request may also be used to retrieve service The <getServiceBoundary> request may also be used to retrieve service
boundaries that are expressed as civic addresses, as illustrated in boundaries that are expressed as civic addresses, as illustrated in
Figure 11. Figure 11.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundaryResponse <getServiceBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1"> xmlns="urn:ietf:params:xml:ns:lost1">
<serviceBoundary <serviceBoundary
profile="civic"> profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country> <country>US</country>
<A1>New York</A1> <A1>New York</A1>
<A3>New York</A3> <A3>New York</A3>
</civicAddress> </civicAddress>
</serviceBoundary> </serviceBoundary>
<path> <path>
<via source="authoritative.example"/> <via source="authoritative.example"/>
<via source="resolver.example"/> <via source="resolver.example"/>
</path> </path>
</getServiceBoundaryResponse> </getServiceBoundaryResponse>
skipping to change at page 26, line 39 skipping to change at page 27, line 39
element, consisting of a whitespace-separated list of service URNs. element, consisting of a whitespace-separated list of service URNs.
The query and response are illustrated in Figure 14 and in Figure 15, The query and response are illustrated in Figure 14 and in Figure 15,
respectively. respectively.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation <listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" xmlns:p2="http://www.opengis.net/gml"
recursive="true"> recursive="true">
<location profile="geodetic-2d"> <location profile="geodetic-2d">
<p2:Point id="point1" srsName="epsg:4326"> <p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
<p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> <p2:pos>-34.407 150.883</p2:pos>
</p2:Point> </p2:Point>
</location> </location>
<service>urn:service:sos</service> <service>urn:service:sos</service>
</listServicesByLocation> </listServicesByLocation>
Figure 14: Example of <ListServicesbyLocation> query Figure 14: Example of <ListServicesbyLocation> query
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse <listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1"> xmlns="urn:ietf:params:xml:ns:lost1">
skipping to change at page 29, line 41 skipping to change at page 30, line 41
1. A client MUST be capable of understanding the response for the 1. A client MUST be capable of understanding the response for the
baseline profiles it used in the request. baseline profiles it used in the request.
2. If a client sends location information conformant to any location 2. If a client sends location information conformant to any location
profile other than geodetic-2d or civic, it MUST also send, in profile other than geodetic-2d or civic, it MUST also send, in
the same request, location information conformant to one of the the same request, location information conformant to one of the
baseline profiles. Otherwise, the server might not be able to baseline profiles. Otherwise, the server might not be able to
understand the request. understand the request.
3. There can only be one instance of each location profile in a 3. A client SHOULD NOT send multiple <location> profiles of derived
from different baseline profiles. Or said another way, a client
should only send location profiles from the same baseline profile
in the same query. If a client has location information
primarily of geodetic nature and location information primarily
of a civic nature, it should send separate requests containing
each type of location information.
4. There can only be one instance of each location profile in a
query. query.
4. Servers MUST implement the geodetic-2d and civic profiles. 5. Servers MUST implement the geodetic-2d and civic profiles.
5. A server uses the first-listed location profile that it 6. A server uses the first-listed location profile that it
understands and ignores the others. understands and ignores the others.
6. If a server receives a request that only contains location 7. If a server receives a request that only contains location
information using profiles it does not understand, the server information using profiles it does not understand, the server
responds with a <locationProfileError> (Section 12.1). responds with a <locationProfileError> (Section 12.1).
7. The <serviceBoundary> element MUST use the same location profile 8. The <serviceBoundary> element MUST use the same location profile
that was used to retrieve the answer and indicates which profile that was used to retrieve the answer and indicates which profile
has been used with the 'profile' attribute. has been used with the 'profile' attribute.
These rules enable the use of location profiles not yet specified, These rules enable the use of location profiles not yet specified,
while ensuring baseline interoperability. Take, for example, this while ensuring baseline interoperability. Take, for example, this
scenario. Client X has had its firmware upgraded to support the scenario. Client X has had its firmware upgraded to support the
uber-complex-3D location profile. Client X sends location uber-complex-3D location profile. Client X sends location
information to Server Y, which does not understand the information to Server Y, which does not understand the
uber-complex-3D location profile. If Client X also sends location uber-complex-3D location profile. If Client X also sends location
information using the geodetic-2D baseline profile, then Server Y information using the geodetic-2D baseline profile, then Server Y
skipping to change at page 31, line 12 skipping to change at page 32, line 12
not be as precise or expressive as desired. This is possible because not be as precise or expressive as desired. This is possible because
both Client X and Server Y understand the baseline profile. both Client X and Server Y understand the baseline profile.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findService <findService
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" xmlns:p2="http://www.opengis.net/gml"
recursive="true" recursive="true"
serviceBoundary="value"> serviceBoundary="value">
<location profile="uber-complex-3d"> <location profile="uber-complex-3d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos> <p2:pos>37.775 -122.422</p2:pos>
</p2:Point> </p2:Point>
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <p2:exterior>
<p2:LinearRing> <p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing> </p2:LinearRing>
</p2:exterior> </p2:exterior>
</p2:Polygon> </p2:Polygon>
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>-122.422 37.775</p2:pos> <p2:pos>-122.422 37.775</p2:pos>
</p2:Point> </p2:Point>
</location> </location>
<location profile="geodetic-2d"> <location profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos> <p2:pos>37.775 -122.422</p2:pos>
</p2:Point> </p2:Point>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 16: Example of a <findServices> query with baseline profile Figure 16: Example of a <findServices> query with baseline profile
interoperability interoperability
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse <findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/"> xmlns:p2="http://www.opengis.net/">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example" source="authoritative.example"
sourceId="cf19bbb038fb4ade95852795f045387d" sourceId="cf19bbb038fb4ade95852795f045387d"
version="1"> version="1">
<displayName xml:lang="en"> <displayName xml:lang="en">
San Francisco Police Department New York City Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <p2:exterior>
<p2:LinearRing> <p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos>
skipping to change at page 32, line 46 skipping to change at page 33, line 46
<via source="resolver.example"/> <via source="resolver.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 17: Example of a <findServiceResponse> message with baseline Figure 17: Example of a <findServiceResponse> message with baseline
profile interoperability profile interoperability
11.2. Two Dimensional Geodetic Profile 11.2. Two Dimensional Geodetic Profile
The geodetic-2d location profile is identified by geodetic-2d. The geodetic-2d location profile is identified by geodetic-2d.
Clients use this profile by placing a GML [13] <position> element Clients use this profile by placing a <Point> element, as described
within the <location> element. This is defined by the 'point2D' in Section 7.2.1 of [13], within the <location> element. Section
pattern in the LoST schema (see Section 14). 7.2.1 of [13] describes the specification of a <Point> with either a
two dimensional position (latitude and longitude) or three
dimensional position (latitude, longitude, and altitude). A client
MAY use the three dimensional position, and servers MAY interpret a
three dimensional position as a two dimensional position by ignoring
altitude.
Servers use this profile by placing a GML [13] <Polygon> element Servers use this profile by placing a <Polygon> element, as described
within the <serviceBoundary> element. This is defined by the in Section 7.2.2 of [13], within the <serviceBoundary> element. This
'polygon' pattern in the LoST schema (see Section 14). is defined by the 'polygon' pattern in the LoST schema (see
Section 14).
With respect to the description in Section 7.2.2 of [13] the
restriction to 16 points for a polygon is not applicable to this
document. With this profile servers MUST use WGS 84 (latitude,
longitude), i.e., the srsName set to 'urn:ogc:def:crs:EPSG::4326'
where altitude information is omitted. The orientation of the points
in the polygon is upward normal as described in Section 7.2.2 of
[13].
11.3. Basic Civic Profile 11.3. Basic Civic Profile
The basic-civic location profile is identified by the token 'civic'. The basic-civic location profile is identified by the token 'civic'.
Clients use this profile by placing a <civicAddress> element, defined Clients use this profile by placing a <civicAddress> element, defined
in [11], within the <location> element. in [10], within the <location> element.
Servers use this profile by placing a <civicAddress> element, defined Servers use this profile by placing a <civicAddress> element, defined
in [11], within the <serviceBoundary> element. in [10], within the <serviceBoundary> element.
12. Errors, Warnings, and Redirects 12. Errors, Warnings, and Redirects
When a LoST server cannot fulfill a request completely, it can return When a LoST server cannot fulfill a request completely, it can return
either an error or a warning, depending on the severity of the either an error or a warning, depending on the severity of the
problem. It returns an error element if no useful response can be problem. It returns an error element if no useful response can be
returned for the query. It returns a <warnings> element as part of returned for the query. It returns a <warnings> element as part of
another response element if it was able to respond in part, but the another response element if it was able to respond in part, but the
response may not be quite what the client had desired. For both response may not be quite what the client had desired. This document
elements, the 'source' attribute names the server that originally does not define warnings. For both elements, the 'source' attribute
generated the error or warning, such as the authoritative server. names the server that originally generated the error or warning, such
Unless otherwise noted, all elements below can be either an error or as the authoritative server. Unless otherwise noted, all elements
a warning, depending on whether a default response, such as a below can be either an error or a warning, depending on whether a
mapping, is included. default response, such as a mapping, is included.
12.1. Errors 12.1. Errors
LoST defines a pattern for errors, defined as <errors> elements in LoST defines a pattern for errors, defined as <errors> elements in
the Relax NG schema. This pattern defines a 'message' attribute the Relax NG schema. This pattern defines a 'message' attribute
containing human readable text and an 'xml:lang' attribute denoting containing human readable text and an 'xml:lang' attribute denoting
the language of the human readable text. One or more such error the language of the human readable text. One or more such error
elements are contained in the <errors> element. elements are contained in the <errors> element.
The following errors follow this basic pattern: The following errors follow this basic pattern:
skipping to change at page 38, line 10 skipping to change at page 39, line 10
When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP
POST method. All HTTP responses are applicable. The HTTP URL is POST method. All HTTP responses are applicable. The HTTP URL is
derived from the LoST server name via U-NAPTR application, as derived from the LoST server name via U-NAPTR application, as
discussed above discussed above
14. Relax NG Schema 14. 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 = "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:lost1" default namespace ns1 = "urn:ietf:params:xml:ns:lost1"
## ##
## Location-to-Service Translation Protocol (LoST) ## Location-to-Service Translation Protocol (LoST)
## ##
## A LoST XML instance has three request types, each with ## A LoST XML instance has three request types, each with
## a cooresponding response type: find service, list services, ## a cooresponding response type: find service, list services,
## and get service boundary. ## and get service boundary.
## ##
start = start =
findService findService
skipping to change at page 38, line 38 skipping to change at page 39, line 37
| listServicesByLocationResponse | listServicesByLocationResponse
| getServiceBoundaryResponse | getServiceBoundaryResponse
| errors | errors
| redirect | redirect
## ##
## The queries. ## The queries.
## ##
div { div {
findService = findService =
element ns1:findService { element findService {
element ns1:location { locationInformation }+, element location { locationInformation }+,
commonRequestPattern, commonRequestPattern,
attribute validateLocation { attribute validateLocation {
xsd:boolean >> a:defaultValue [ "false" ] xsd:boolean >> a:defaultValue [ "false" ]
}?, }?,
attribute serviceBoundary { attribute serviceBoundary {
("reference" | "value") >> a:defaultValue [ "reference" ] ("reference" | "value") >> a:defaultValue [ "reference" ]
}?, }?,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
} }
listServices = element ns1:listServices { commonRequestPattern } listServices = element listServices { commonRequestPattern }
listServicesByLocation = listServicesByLocation =
element ns1:listServicesByLocation { element listServicesByLocation {
element ns1:location { locationInformation }*, element location { locationInformation }*,
commonRequestPattern, commonRequestPattern,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
} }
getServiceBoundary = getServiceBoundary =
element ns1:getServiceBoundary { element getServiceBoundary { serviceBoundaryKey, extensionPoint }
serviceBoundaryKey, extensionPoint
}
} }
## ##
## The responses. ## The responses.
## ##
div { div {
findServiceResponse = findServiceResponse =
element ns1:findServiceResponse { element findServiceResponse {
mapping+, locationValidation?, commonResponsePattern mapping+, locationValidation?, commonResponsePattern
} }
listServicesResponse = listServicesResponse =
element ns1:listServicesResponse { element listServicesResponse { serviceList, commonResponsePattern }
serviceList, commonResponsePattern
}
listServicesByLocationResponse = listServicesByLocationResponse =
element ns1:listServicesByLocationResponse { element listServicesByLocationResponse {
serviceList, commonResponsePattern serviceList, commonResponsePattern
} }
getServiceBoundaryResponse = getServiceBoundaryResponse =
element ns1:getServiceBoundaryResponse { element getServiceBoundaryResponse {
serviceBoundary, commonResponsePattern serviceBoundary, commonResponsePattern
} }
} }
## ##
## A pattern common to some of the queries. ## A pattern common to some of the queries.
## ##
div { div {
commonRequestPattern = service, extensionPoint commonRequestPattern = service, path?, extensionPoint
} }
## ##
## A pattern common to responses. ## A pattern common to responses.
## ##
div { div {
commonResponsePattern = warnings*, path, extensionPoint commonResponsePattern = warnings*, path, extensionPoint
} }
## ##
## Location Information ## Location Information
## ##
div { div {
locationInformation = locationInformation =
extensionPoint+, extensionPoint+,
attribute profile { xsd:NMTOKEN } attribute profile { xsd:NMTOKEN }
} }
## ##
## Service Boundary ## Service Boundary
## ##
div { div {
serviceBoundary = element ns1:serviceBoundary { locationInformation }+ serviceBoundary = element serviceBoundary { locationInformation }+
} }
## ##
## Service Boundary Reference ## Service Boundary Reference
## ##
div { div {
serviceBoundaryReference = serviceBoundaryReference =
element ns1:serviceBoundaryReference { element serviceBoundaryReference {
source, serviceBoundaryKey, extensionPoint source, serviceBoundaryKey, extensionPoint
} }
serviceBoundaryKey = attribute key { xsd:token } serviceBoundaryKey = attribute key { xsd:token }
} }
## ##
## Path - ## Path -
## Contains a list of via elements - ## Contains a list of via elements -
## places through which information flowed ## places through which information flowed
## ##
div { div {
path = path =
element ns1:path { element path {
element ns1:via { source, extensionPoint }* element via { source, extensionPoint }+
} }
} }
## ##
## Expires pattern ## Expires pattern
## ##
div { div {
expires = attribute expires { xsd:dateTime } expires =
attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
} }
## ##
## A QName list ## A QName list
## ##
div { div {
qnameList = list { xsd:QName* } qnameList = list { xsd:QName* }
} }
## ##
## A location-to-service mapping. ## A location-to-service mapping.
## ##
div { div {
mapping = mapping =
element ns1:mapping { element mapping {
element ns1:displayName { element displayName {
xsd:string, xsd:string,
attribute xml:lang { xsd:language } attribute xml:lang { xsd:language }
}*, }*,
service, service,
(serviceBoundary | serviceBoundaryReference)?, (serviceBoundary | serviceBoundaryReference)?,
element ns1:uri { xsd:anyURI }*, element uri { xsd:anyURI }*,
element ns1:serviceNumber { element serviceNumber {
xsd:string { pattern = "[0-9*#]+" } xsd:string { pattern = "[0-9*#]+" }
}?, }?,
extensionPoint, extensionPoint,
expires, expires,
attribute lastUpdated { xsd:dateTime }, attribute lastUpdated { xsd:dateTime },
source, source,
attribute sourceId { xsd:token }, attribute sourceId { xsd:token },
attribute version { xsd:positiveInteger },
message message
} }
} }
## ##
## Location validation ## Location validation
## ##
div { div {
locationValidation = locationValidation =
element ns1:locationValidation { element locationValidation {
element ns1:valid { qnameList }?, element valid { qnameList }?,
element ns1:invalid { qnameList }?, element invalid { qnameList }?,
element ns1:unchecked { qnameList }?, element unchecked { qnameList }?,
extensionPoint extensionPoint
} }
} }
## ##
## Errors and Warnings Container. ## Errors and Warnings Container.
## ##
div { div {
errorContainer = errorContainer =
(badRequest? (badRequest?
skipping to change at page 42, line 17 skipping to change at page 43, line 11
& serviceSubstitution? & serviceSubstitution?
& forbidden? & forbidden?
& notFound? & notFound?
& loop? & loop?
& serviceNotImplemented? & serviceNotImplemented?
& serverTimeout? & serverTimeout?
& serverError? & serverError?
& locationProfileUnrecognized?), & locationProfileUnrecognized?),
extensionPoint, extensionPoint,
source source
errors = element ns1:errors { errorContainer } errors = element errors { errorContainer }
warnings = element ns1:warnings { errorContainer } warnings = element warnings { errorContainer }
} }
## ##
## Basic Errors ## Basic Errors
## ##
div { div {
## ##
## Error pattern. ## Error pattern.
## ##
basicError = message, extensionPoint basicError = message, extensionPoint
badRequest = element ns1:badRequest { basicError } badRequest = element badRequest { basicError }
internalError = element ns1:internalError { basicError } internalError = element internalError { basicError }
serviceSubstitution = element ns1:serviceSubstitution { basicError } serviceSubstitution = element serviceSubstitution { basicError }
forbidden = element ns1:forbidden { basicError } forbidden = element forbidden { basicError }
notFound = element ns1:notFound { basicError } notFound = element notFound { basicError }
loop = element ns1:loop { basicError } loop = element loop { basicError }
serviceNotImplemented = serviceNotImplemented = element serviceNotImplemented { basicError }
element ns1:serviceNotImplemented { basicError } serverTimeout = element serverTimeout { basicError }
serverTimeout = element ns1:serverTimeout { basicError } serverError = element serverError { basicError }
serverError = element ns1:serverError { basicError }
locationProfileUnrecognized = locationProfileUnrecognized =
element ns1:locationProfileUnrecognized { element locationProfileUnrecognized {
attribute unsupportedProfiles { xsd:NMTOKENS }, attribute unsupportedProfiles { xsd:NMTOKENS },
basicError basicError
} }
} }
## ##
## Redirect. ## Redirect.
## ##
div { div {
## ##
## Redirect pattern ## Redirect pattern
## ##
redirect = redirect =
element ns1:redirect { element redirect {
attribute target { appUniqueString }, attribute target { appUniqueString },
source, source,
message, message,
extensionPoint extensionPoint
} }
} }
## ##
## Some common patterns. ## Some common patterns.
## ##
div { div {
message = message =
(attribute message { xsd:string }, (attribute message { xsd:string },
attribute xml:lang { xsd:language })? attribute xml:lang { xsd:language })?
service = element ns1:service { xsd:anyURI }? service = element service { xsd:anyURI }?
appUniqueString = appUniqueString =
xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
source = attribute source { appUniqueString } source = attribute source { appUniqueString }
serviceList = serviceList =
element ns1:serviceList { element serviceList {
list { xsd:anyURI* } list { xsd:anyURI* }
} }
} }
## ##
## Patterns for inclusion of elements from schemas in ## Patterns for inclusion of elements from schemas in
## other namespaces. ## other namespaces.
## ##
div { div {
skipping to change at page 44, line 12 skipping to change at page 45, line 5
| attribute * { text } | attribute * { text }
| text)* | text)*
## ##
## A point where future extensions ## A point where future extensions
## (elements from other namespaces) ## (elements from other namespaces)
## can be added. ## can be added.
## ##
extensionPoint = notLost* extensionPoint = notLost*
##
## A 2D point from GML.
##
point2d =
element Point {
attribute srsName { "urn:ogc:def:crs:EPSG::4326" },
pos
}
##
## A GML position
##
pos =
element pos {
list { xsd:double }
}
##
## A Linear Ring from GML.
##
linearRing = element LinearRing { pos, pos, pos, pos+ }
##
## A Polygon from GML.
##
polygon =
element Polygon {
attribute srsName { "urn:ogc:def:crs:EPSG::4326" },
element exterior { linearRing },
element interior { linearRing }*
}
} }
Figure 20: RelaxNG schema Figure 20: RelaxNG schema
15. Internationalization Considerations 15. 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
skipping to change at page 46, line 35 skipping to change at page 47, line 35
o o
Application Protocol Tag: https Application Protocol Tag: https
Defining Publication: RFC 2818 [4] Defining Publication: RFC 2818 [4]
16.2. Content-type registration for 'application/lost+xml' 16.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 [8] and guidelines in RFC according to the procedures of RFC 4288 [7] and guidelines in RFC
3023 [5]. 3023 [5].
MIME media type name: application MIME media type name: application
MIME subtype name: lost+xml MIME subtype name: lost+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: charset
skipping to change at page 48, line 7 skipping to change at page 49, line 7
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: Author:
This specification is a work item of the IETF ECRIT working group, This specification is a work item of the IETF ECRIT working group,
with mailing list address <ecrit@ietf.org>. with mailing list address <ecrit@ietf.org>.
Change controller: Change controller:
The IESG <iesg@ietf.org> delegated to the IETF ECRIT working The IESG <iesg@ietf.org>
group, if it is still active.
16.3. LoST Relax NG Schema Registration 16.3. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:lost1 URI: urn:ietf:params:xml:ns:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com). (Hannes.Tschofenig@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 14. Its first line is in Section 14. Its first line is
skipping to change at page 51, line 27 skipping to change at page 52, line 27
o Martin Thomson (Review December 2006) o Martin Thomson (Review December 2006)
o Barbara Stark (Review January 2007) o Barbara Stark (Review January 2007)
o Patrik Faeltstroem (Review January 2007 o Patrik Faeltstroem (Review January 2007
o Shida Schubert (Review January 2007 as a designated expert o Shida Schubert (Review January 2007 as a designated expert
reviewer) reviewer)
o Jonathan Rosenberg (Review February 2007)
o Tom Taylor (Review February 2007)
o Theresa Reese (Review February 2007)
o Shida Schubert (Review February 2007)
We would also like to thank the following working group members for We would also like to thank the following working group members for
their input to selected design aspects of the LoST protocol: their input to selected design aspects of the LoST protocol:
o Leslie Daigle and Martin Thomson (DNS-based LoST discovery o Leslie Daigle and Martin Thomson (DNS-based LoST discovery
procedure) procedure)
o John Schnizlein (authoritive LoST answers) o John Schnizlein (authoritive LoST answers)
o Rohan Mahy (display names) o Rohan Mahy (display names)
skipping to change at page 52, line 4 skipping to change at page 53, line 12
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James
Winterbottom (Indication of PSAP Confidence Level) Winterbottom (Indication of PSAP Confidence Level)
o Martin Thomson (service boundary references) o Martin Thomson (service boundary references)
o Martin Thomson (service URN in LoST response message) o Martin Thomson (service URN in LoST response message)
o Cullen Jennings (service boundaries) o Cullen Jennings (service boundaries)
o Clive D.W. Feather, Martin Thomson (Validation Functionality) o Clive D.W. Feather, Martin Thomson (Validation Functionality)
o Roger Marshall (PSAP Preference in LoST response) o Roger Marshall (PSAP Preference in LoST response)
o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor,
Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W.
Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-
Francois Mule, Pierre Desjardins (Location Profiles) Francois Mule, Pierre Desjardins (Location Profiles)
o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson,
Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage,
Keith (List Services functionality) Keith (List Services functionality)
o Thomson, Martin, Michael Hammer (Mapping of Services) o Thomson, Martin, Michael Hammer (Mapping of Services)
o Shida Schubert, James Winterbottom, Keith Drage (default service o Shida Schubert, James Winterbottom, Keith Drage (default service
URN) URN)
o Otmar Lendl (LoST aggregation) o Otmar Lendl (LoST aggregation)
o Tom Taylor (Terminology)
Klaus Darilion and Marc Linsner provided miscellaneous input to the Klaus Darilion and Marc Linsner provided miscellaneous input to the
design of the protocol. Finally, we would like to thank Brian Rosen design of the protocol. Finally, we would like to thank Brian Rosen
who participated in almost every discussion thread. who participated in almost every discussion thread.
19. Open Issues 19. 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/
20. References 20. References
skipping to change at page 54, line 25 skipping to change at page 55, line 25
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [6] Peterson, J., "A Presence-based GEOPRIV Location Object
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[7] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[8] Freed, N. and J. Klensin, "Media Type Specifications and [7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[9] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [8] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006. RFC 4395, February 2006.
[10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-ietf-ecrit-service-urn-05 (work in progress), draft-ietf-ecrit-service-urn-05 (work in progress),
August 2006. August 2006.
[11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in
progress), September 2006. progress), February 2007.
[12] Daigle, L., "Domain-based Application Service Location Using [11] 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-01 (work in progress), October 2006. draft-daigle-unaptr-02 (work in progress), February 2007.
[13] OpenGIS, "Open Geography Markup Language (GML) Implementation [12] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
Specification", OGC OGC 02-023r4, January 2003. "Geographic information - Geography Markup Language (GML)", OGC
Standard OpenGIS 03-105r1, April 2004.
[13] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
Schema for use by the Internet Engineering Task Force (IETF)",
Candidate OpenGIS Implementation Specification , December 2006.
20.2. Informative References 20.2. Informative References
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC 3921, Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
October 2004. October 2004.
skipping to change at page 56, line 9 skipping to change at page 57, line 9
progress), December 2006. progress), December 2006.
[20] Rosen, B. and J. Polk, "Best Current Practice for [20] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006. draft-ietf-ecrit-phonebcp-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 request types, each with A LoST XML instance has three request types, each with
a cooresponding response type: find service, list services, a cooresponding response type: find service, list services,
and get service boundary. and get service boundary.
</a:documentation> </a:documentation>
<choice> <choice>
<ref name="findService" /> <ref name="findService" />
<ref name="listServices" /> <ref name="listServices" />
<ref name="listServicesByLocation" /> <ref name="listServicesByLocation" />
<ref name="getServiceBoundary" /> <ref name="getServiceBoundary" />
<ref name="findServiceResponse" /> <ref name="findServiceResponse" />
<ref name="listServicesResponse" /> <ref name="listServicesResponse" />
<ref name="listServicesByLocationResponse" /> <ref name="listServicesByLocationResponse" />
<ref name="getServiceBoundaryResponse" /> <ref name="getServiceBoundaryResponse" />
<ref name="errors" /> <ref name="errors" />
<ref name="redirect" /> <ref name="redirect" />
</choice> </choice>
</start> </start>
<div>
<div> <a:documentation>
<a:documentation>
The queries. The queries.
</a:documentation> </a:documentation>
<define name="findService"> <define name="findService">
<element name="findService"> <element name="findService">
<oneOrMore> <oneOrMore>
<element name="location"> <element name="location">
<ref name="locationInformation" /> <ref name="locationInformation" />
</element> </element>
</oneOrMore> </oneOrMore>
skipping to change at page 57, line 4 skipping to change at page 57, line 49
<oneOrMore> <oneOrMore>
<element name="location"> <element name="location">
<ref name="locationInformation" /> <ref name="locationInformation" />
</element> </element>
</oneOrMore> </oneOrMore>
<ref name="commonRequestPattern" /> <ref name="commonRequestPattern" />
<optional> <optional>
<attribute name="validateLocation"> <attribute name="validateLocation">
<data type="boolean" /> <data type="boolean" />
<a:defaultValue>false</a:defaultValue> <a:defaultValue>false</a:defaultValue>
</attribute> </attribute>
</optional> </optional>
<optional> <optional>
<attribute name="serviceBoundary"> <attribute name="serviceBoundary">
<choice> <choice>
<value>reference</value> <value>reference</value>
<value>value</value> <value>value</value>
</choice> </choice>
<a:defaultValue>reference</a:defaultValue> <a:defaultValue>reference</a:defaultValue>
</attribute> </attribute>
</optional> </optional>
<optional> <optional>
<attribute name="recursive"> <attribute name="recursive">
<data type="boolean" /> <data type="boolean" />
<a:defaultValue>true</a:defaultValue> <a:defaultValue>false</a:defaultValue>
</attribute> </attribute>
</optional> </optional>
</element> </element>
</define> </define>
<define name="listServices"> <define name="listServices">
<element name="listServices"> <element name="listServices">
<ref name="commonRequestPattern" /> <ref name="commonRequestPattern" />
</element> </element>
</define> </define>
skipping to change at page 59, line 7 skipping to change at page 60, line 4
<ref name="commonResponsePattern" /> <ref name="commonResponsePattern" />
</element> </element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
A pattern common to some of the queries. A pattern common to some of the queries.
</a:documentation> </a:documentation>
<define name="commonRequestPattern"> <define name="commonRequestPattern">
<ref name="service" /> <ref name="service" />
<optional>
<ref name="path" />
</optional>
<ref name="extensionPoint" /> <ref name="extensionPoint" />
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
A pattern common to responses. A pattern common to responses.
</a:documentation> </a:documentation>
<define name="commonResponsePattern"> <define name="commonResponsePattern">
skipping to change at page 60, line 41 skipping to change at page 61, line 40
<div> <div>
<a:documentation> <a:documentation>
Path - Path -
Contains a list of via elements - Contains a list of via elements -
places through which information flowed places through which information flowed
</a:documentation> </a:documentation>
<define name="path"> <define name="path">
<element name="path"> <element name="path">
<zeroOrMore> <oneOrMore>
<element name="via"> <element name="via">
<ref name="source" /> <ref name="source" />
<ref name="extensionPoint" /> <ref name="extensionPoint" />
</element> </element>
</zeroOrMore> </oneOrMore>
</element> </element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Expires pattern Expires pattern
</a:documentation> </a:documentation>
<define name="expires"> <define name="expires">
<attribute name="expires"> <attribute name="expires">
<data type="dateTime"/> <choice>
<data type="dateTime"/>
<value>NO-CACHE</value>
<value>NO-EXPIRATION</value>
</choice>
</attribute> </attribute>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
A QName list A QName list
</a:documentation> </a:documentation>
<define name="qnameList"> <define name="qnameList">
skipping to change at page 62, line 23 skipping to change at page 63, line 27
</optional> </optional>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
<ref name="expires"/> <ref name="expires"/>
<attribute name="lastUpdated"> <attribute name="lastUpdated">
<data type="dateTime"/> <data type="dateTime"/>
</attribute> </attribute>
<ref name="source" /> <ref name="source" />
<attribute name="sourceId"> <attribute name="sourceId">
<data type="token" /> <data type="token" />
</attribute> </attribute>
<attribute name="version">
<data type="positiveInteger" />
</attribute>
<ref name="message"/> <ref name="message"/>
</element> </element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Location validation Location validation
</a:documentation> </a:documentation>
skipping to change at page 68, line 26 skipping to change at page 69, line 26
<a:documentation> <a:documentation>
A point where future extensions A point where future extensions
(elements from other namespaces) (elements from other namespaces)
can be added. can be added.
</a:documentation> </a:documentation>
<zeroOrMore> <zeroOrMore>
<ref name="notLost" /> <ref name="notLost" />
</zeroOrMore> </zeroOrMore>
</define> </define>
<define name="point2d">
<a:documentation>
A 2D point from GML.
</a:documentation>
<element name="Point" ns="http://www.opengis.net/gml">
<attribute name="srsName">
<value>urn:ogc:def:crs:EPSG::4326</value>
</attribute>
<ref name="pos"/>
</element>
</define>
<define name="pos">
<a:documentation>
A GML position
</a:documentation>
<element name="pos" ns="http://www.opengis.net/gml">
<list>
<data type="double"/>
</list>
</element>
</define>
<define name="linearRing">
<a:documentation>
A Linear Ring from GML.
</a:documentation>
<element name="LinearRing"
ns="http://www.opengis.net/gml">
<ref name="pos"/>
<ref name="pos"/>
<ref name="pos"/>
<oneOrMore>
<ref name="pos"/>
</oneOrMore>
</element>
</define>
<define name="polygon">
<a:documentation>
A Polygon from GML.
</a:documentation>
<element name="Polygon"
ns="http://www.opengis.net/gml">
<attribute name="srsName">
<value>urn:ogc:def:crs:EPSG::4326</value>
</attribute>
<element name="exterior">
<ref name="linearRing"/>
</element>
<zeroOrMore>
<element name="interior">
<ref name="linearRing"/>
</element>
</zeroOrMore>
</element>
</define>
</div> </div>
</grammar> </grammar>
Figure 24 Figure 24
Authors' Addresses Authors' Addresses
Ted Hardie Ted Hardie
Qualcomm, Inc. Qualcomm, Inc.
 End of changes. 134 change blocks. 
385 lines changed or deleted 415 lines changed or added

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