draft-ietf-ecrit-lost-02.txt   draft-ietf-ecrit-lost-03.txt 
Network Working Group 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: April 25, 2007 SunRocket Expires: July 21, 2007 SunRocket
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
H. Tschofenig H. Tschofenig
Siemens Siemens Networks GmbH & Co KG
October 22, 2006 January 17, 2007
LoST: A Location-to-Service Translation Protocol LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-02.txt draft-ietf-ecrit-lost-03.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 April 25, 2007. This Internet-Draft will expire on July 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 2. Terminology and Requirements Notation . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7
4. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 8 4. LoST Uniform Resource Locators and Their Resolution . . . . . 8
5. LoST Uniform Resource Locators and Their Resolution . . . . . 9 5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 9
6. Mapping a Location and Service to URLs: <findService> . . . . 10 5.1. Data source and version: The 'source', 'sourceId' and
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 'version' Attributes . . . . . . . . . . . . . . . . . . . 9
6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9
6.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 10 5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9
6.2.2. Civic Address Mapping Example . . . . . . . . . . . . 11 5.4. Describing the Service with the <displayName> Element . . 10
6.3. Components of <findService> Request . . . . . . . . . . . 13 5.5. The Mapped Service: the <service> Element . . . . . . . . 10
6.3.1. The <location> Element . . . . . . . . . . . . . . . . 13 5.6. Defining the Service Region with the <serviceBoundary>
6.3.2. The <service> Element . . . . . . . . . . . . . . . . 13 Element . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3.3. Recursion or Redirection . . . . . . . . . . . . . . . 13 5.7. Service Boundaries by Reference: the
6.3.4. Configuring the Response . . . . . . . . . . . . . . . 14 <serviceBoundaryReference> Element . . . . . . . . . . . . 11
6.4. Components of the Mapping Response 5.8. The Service Number . . . . . . . . . . . . . . . . . . . . 11
<findServiceResponse> . . . . . . . . . . . . . . . . . . 16 5.9. Service URLs: the <uri> Element . . . . . . . . . . . . . 11
6.4.1. Source of Response: <via> Element . . . . . . . . . . 16 6. Path of Request: <path> Element . . . . . . . . . . . . . . . 12
6.4.2. Service URLs: the <uri> Element . . . . . . . . . . . 16 7. Mapping a Location and Service to URLs: <findService> . . . . 13
6.4.3. Describing the Service with the <displayName> 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13
Element . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.4.4. Approximating Services: the <service> Element . . . . 17 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 13
6.4.5. Defining the Service Region with the 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 14
<serviceBoundary> Element . . . . . . . . . . . . . . 17 7.3. Components of the <findService> Request . . . . . . . . . 16
6.4.6. Service Boundaries by Reference: the 7.3.1. The <location> Element . . . . . . . . . . . . . . . . 16
<serviceBoundaryReference> Element . . . . . . . . . . 17 7.3.2. Identifying the Service: The <service> Element . . . 17
6.4.7. The Service Number . . . . . . . . . . . . . . . . . . 18 7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 17
6.4.8. Civic Address Validation . . . . . . . . . . . . . . . 18 7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 17
6.4.9. Validity: The 'timeToLive' Attribute . . . . . . . . . 18 7.3.5. Requesting Civic Location Validation . . . . . . . . . 17
7. Retrieving the Service Boundary via <getServiceBoundary> . . . 19 7.4. Components of the Mapping Response
8. List Services: <listServices> . . . . . . . . . . . . . . . . 21 <findServiceResponse> . . . . . . . . . . . . . . . . . . 19
9. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 23 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 23 7.4.2. Civic Address Validation: the
9.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 26 <locationValidation> Element . . . . . . . . . . . . . 20
9.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 26 8. Retrieving the Service Boundary via <getServiceBoundary> . . . 21
10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 27 9. List Services: <listServices> . . . . . . . . . . . . . . . . 24
10.1. Basic Errors . . . . . . . . . . . . . . . . . . . . . . . 27 10. List Services By Location: <listServicesByLocation> . . . . . 25
10.2. Response Errors . . . . . . . . . . . . . . . . . . . . . 27 11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 27
10.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 28
11. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 29 11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 30
12. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30 11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 31
13. Internationalization Considerations . . . . . . . . . . . . . 37 12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 32
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 38 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.2. Content-type registration for 'application/lost+xml' . . . 38 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 34
14.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 40 13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 35
14.4. LoST Namespace Registration . . . . . . . . . . . . . . . 40 14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 36
14.5. Registration Template . . . . . . . . . . . . . . . . . . 41 15. Internationalization Considerations . . . . . . . . . . . . . 43
14.6. LoST Location Profile Registry . . . . . . . . . . . . . . 42 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
15. Security Considerations . . . . . . . . . . . . . . . . . . . 43 16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 44
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 16.2. Content-type registration for 'application/lost+xml' . . . 44
17. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45 16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 46
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 46
18.1. Normative References . . . . . . . . . . . . . . . . . . . 46 16.5. URL Registration Template . . . . . . . . . . . . . . . . 47
18.2. Informative References . . . . . . . . . . . . . . . . . . 47 16.6. LoST Location Profile Registry . . . . . . . . . . . . . . 48
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 48 17. Security Considerations . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . . . . . 62 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 52
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
20.1. Normative References . . . . . . . . . . . . . . . . . . . 53
20.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
Intellectual Property and Copyright Statements . . . . . . . . . . 70
1. Introduction 1. Introduction
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 [8] to one or [10] and location information compatible with PIDF-LO [8], namely
more service contact URIs. Example contact URI schemes include sip revised civic location information [11] and GML [13]) to one or more
[14], xmpp [15], and tel [16]. While the initial focus is on service URL. Example service URL schemes include sip [14], xmpp
providing mapping functions for emergency services, it is likely that [15], and tel [16]. While the initial focus is on providing mapping
the protocol is applicable to any service URN. For example, in the functions for emergency services, it is likely that the protocol is
United States, the "2-1-1" and "3-1-1" services follow a similar applicable to any service URN. For example, in the United States,
location-to-service behavior as emergency services. the "2-1-1" and "3-1-1" service numbers follow a similar location-to-
service behavior as emergency services.
This document names this protocol "LoST", for Location-to-Service This document names this protocol "LoST", for Location-to-Service
Translation. LoST Satisfies the requirements [18] for mapping Translation. LoST Satisfies the requirements [18] for mapping
protocols. LoST provides a number of operations, centered around protocols. LoST provides a number of operations, centered around
mapping locations and service URNs to URIs and associated mapping locations and service URNs to service URLs and associated
information. LoST mapping queries can contain either civic or information. LoST mapping queries can contain either civic or
geodetic location information. For civic addresses, LoST can geodetic location information. For civic addresses, LoST can
indicate which parts of the civic address are known to be valid or indicate which parts of the civic address are known to be valid or
invalid, thus providing address validation. LoST indicates errors in invalid, thus providing address validation (see Section 3.5 of [18]
the location data to facilitate debugging and proper user feedback, for a description of validation). LoST indicates errors in the
but also provides best-effort answers. location data to facilitate debugging and proper user feedback, but
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, LoST caches individual mappings and indicates the region round trips and to provide robustness against network failures, LoST
for which the same answer would be returned ("service region"). caches individual mappings and indicates the region for which the
same answer would be returned ("service region").
As currently defined, LoST messages are carried in HTTP and HTTPS As defined in this document, LoST messages are carried in HTTP and
protocol exchanges, facilitating use of TLS for protecting the HTTPS protocol exchanges, facilitating use of TLS for protecting the
integrity and confidentiality of requests and responses. integrity and confidentiality of requests and responses.
This document focuses on the description of the protocol between the This document focuses on the description of the protocol between the
mapping client (seeker or resolver) and the mapping server (resolver mapping client (seeker or resolver) and the mapping server (resolver
or other servers). The relationship between other functions, such as or other servers). The relationship between other functions, such as
discovery of mapping servers, data replication and the overall discovery of mapping servers, data replication and the overall
mapping server architecture are described in a separate document mapping server architecture are described in a separate document
[19]. [19].
The query message carries location information and a service The query message carries location information and a service
identifier encoded as a Uniform Resource Name (URN) (see [10]) from identifier encoded as a Uniform Resource Name (URN) (see [10]) from
the LoST client to the LoST server. The LoST server uses its the LoST client to the LoST server. The LoST server uses its
database to map the input values to 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 URL (Section 5). In another LoST server, identified by a LoST URL (Section 4). In
addition to the mapping function described in Section 6, the protocol addition to the mapping function described in Section 7, the protocol
also allows to retrieve the service boundary Section 7 and to list also allows to retrieve the service boundary (see Section 8) and to
the services available for a particular location Section 8. list the services available for a particular location (see
Section 10) or supported by a particular server (see Section 9).
2. 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].
3. Terminology
This document furthermore uses the terminology defined in [18]. This document furthermore uses the terminology defined in [18].
In examples, the XML sent by the client is prepended with "C:" and 3. Overview of Protocol Usage
the XML sent by the server is prepended with "S:".
4. Overview of Protocol Usage
The client may perform the mapping at any time. Among the common The client may perform the mapping at any time. Among the common
triggers for mapping requests are: triggers for mapping requests 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. returned in an earlier LoST query.
3. When cached mapping information has expired. 3. When cached mapping information has expired.
4. When invoking a particular service. At that time, a client may 4. 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 BCP such as [20] governs whether a client is A service-specific Best Current Practice (BCP) document, such as
expected to invoke the mapping service just before needing the [20], governs whether a client is expected to invoke the mapping
service or whether to rely on cached answers. Cache entries expire service just before needing the service or whether to rely on cached
according to their time-to-live value (see Section 6.4.9, or they answers. Cache entries expire at their expiration time (see
become invalid if the caller's device moves beyond the boundaries of Section 5.3), or they become invalid if the caller's device moves
the service region. beyond the boundaries of the service region.
5. LoST Uniform Resource Locators and Their Resolution 4. LoST Uniform Resource Locators and Their Resolution
LoST servers are identified by LoST Uniform Resource Locators (URLs), LoST servers are identified by LoST Uniform Resource Locators (URLs),
which follow the format of URLs defined in RFC 3986 [7], with the which follow the format of URLs defined in RFC 3986 [7], with the
following ABNF: following ABNF:
LoST-URI = "lost:" host LoST-URI = "lost:" host
'host' is defined in Section 3.2.2 of RFC 3986 [7]. 'host' is defined in Section 3.2.2 of RFC 3986 [7].
An example is 'lost:lostserver.example.com' An example is 'lost:lostserver.example.com'
skipping to change at page 10, line 5 skipping to change at page 9, line 5
http://lostserver.example.com, with the former being preferred. http://lostserver.example.com, with the former being preferred.
example.com. example.com.
IN NAPTR 100 10 "u" "LoST:https" IN NAPTR 100 10 "u" "LoST:https"
"!*.!https://lostserver.example.com/secure!" "" "!*.!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http" IN NAPTR 200 10 "u" "LoST:http"
"!*.!http://lostserver.example.com!" "" "!*.!http://lostserver.example.com!" ""
6. Mapping a Location and Service to URLs: <findService> 5. The <mapping> Element
6.1. Overview The <mapping> element is the core data element in LoST, describing a
service region and the associated service URLs. Its parameters
indicate when the mapping was last updated, how long it is valid, its
version and the authoritative source for the mapping, along with a
unique identifier. Elements within the <mapping> element then
provide a human-readable description, the service URN, a service
boundary, the service URIs, and a service number. All elements
except the service URN are optional. Below, we describe the
components in turn.
5.1. Data source and version: The 'source', 'sourceId' and 'version'
Attributes
The 'source', 'sourceId' and 'version' attributes uniquely identify a
particular mapping record. They are created by the authoritative
source for a mapping and never modified when a mapping is served from
a cache. The 'source' attribute contains a LoST URL identifying the
authoritative generator of the mapping. The 'sourceId' attribute
identifies a particular mapping. The attribute contains a token,
which is opaque, but MUST be unique among all different mappings
maintained by the authoritative source for that particular service.
For example, a UUID is a suitable format. The 'version' attribute is
a positive integer that is incremented by one for each change in the
mapping. Thus, a higher version number refers to a more recent
mapping. A mapping maintains its sourceId value as long as it
remains logically the same, e.g., represents the same service
boundary or replaces an earlier service boundary. A receiver should
be able to replace a mapping with another one having the same
'source' and 'sourceId' and a higher version number. All three
attributes are REQUIRED for all <mapping> elements.
5.2. Time of Last Update: The 'lastUpdated' Attribute
The 'lastUpdated' attribute describes when the mapping was last
changed. The contents of this attribute is a timezoned XML type
dateTime, in canonical representation. The attribute is REQUIRED.
5.3. Validity: The 'expires' Attribute
The 'expires' attribute contains the absolute time until which the
mapping is to be considered valid. The contents of this attribute is
a timezoned XML type dateTime, in canonical representation. See
Section 3 regarding how this value is to be utilized with a cache.
The 'expires' attribute is REQUIRED to be included in the <mapping>
element.
On occasion, a resolver may be forced to return an expired mapping if
it cannot reach the authoritative server or the server fails to
return a usable answer. Seekers and resolvers MAY cache the mapping
so that they have at least some information available. Resolvers
SHOULD re-attempt the query each time a seeker requests a mapping.
5.4. Describing the Service with the <displayName> Element
The <displayName> element describes the service with a string that is
suitable for display to human users, annotated with the 'xml:lang'
attribute that contains a language tag to aid in the rendering of
text.
5.5. The Mapped Service: the <service> Element
The 'service' element identifies the service for which this mapping
applies. It is usually the same service URN as in the request.
However, if the requested service, identified by the service URN [10]
in the <service> element in the request, does not exist for the
location indicated, the server can either return an
<serviceNotImplemented> (Section 12.1) error or can provide an
alternate service that approximates the desired service for that
location. In the latter case, the server MUST include a <service>
element with the alternative service URN. The choice of service URN
is left to local policy, but the alternate service should be able to
satisfy the original service request. The <service> element may also
be required if the mapping is to be digitally signed.
5.6. Defining the Service Region with the <serviceBoundary> Element
A response can indicate the region for which the service URL returned
would be the same as in the actual query, the so-called _service
region_. The service region can be indicated by value or by
reference (see Section 5.7). If a client moves outside the service
area and wishes to obtain current service data, it MUST send a new
query with its current location. The service region is described by
value in one or more <serviceBoundary> elements, each formatted
according to a different location profile, identified by the
'profile' atribute. The client only processes the first element that
it can understand according to its list of supported location
profiles. Thus, the elements are alternative descriptions of the
same service region, not additive geometries.
The server returns all suitable service regions, using all available
location profiles, so that intermediate caches have this information
available for future queries.
5.7. Service Boundaries by Reference: the <serviceBoundaryReference>
Element
Since geodetic service boundaries may contain thousands of points and
thus be quite large, clients may opt to conserve bandwidth and
request a reference to the service boundary instead of the value
described in Section 5.6. The identifier of the service boundary is
returned as an attribute of the <serviceBoundaryReference> element,
along with a LoST URL identifying the server from where it can be
retrieved. The actual value of the service boundary is then
retrieved with the getServiceBoundary (Section 8) request.
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
particular boundary. If the boundary changes, a new identifier MUST
be chosen. Because of these properties, a client receiving a mapping
response can simply check if it already has a copy of the boundary
with that identifier. If so, it can skip checking with the server
whether the boundary has been updated. Since service boundaries are
likely to remain unchanged for extended periods of time, possibly
exceeding the normal lifetime of the service URL, this approach
avoids refreshing the boundary information even if the cached service
response has gotten stale.
5.8. The Service Number
The service number is returned in the optional <serviceNumber>
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
service.
5.9. Service URLs: the <uri> Element
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
particular significance. Each URL scheme MUST only appear at most
once, but it is permissible to include both secured and regular
versions of a protocol, such as both 'http' and 'https' or 'sip' and
'sips'.
6. Path of Request: <path> Element
To prevent loops and to allow tracing of request and response paths,
all requests that allow recursion include a <path> element that
contains one or more <via> elements, each possessing an attribute
containing a LoST URL. The order of <via> elements corresponds to
the order of LoST servers, i.e., the first <via> element identifies
the server that first received the request from the seeker. The
authoritative server copies the <path> element verbatim into the
response.
If a query is answered iteratively, the querier includes all servers
that it has already contacted.
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,
which got the answer from the LoST server at
polizei.muenchen.de.example.
7. Mapping a Location and Service to URLs: <findService>
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.
6.2. Examples 7.2. Examples
6.2.1. Example Using Geodetic Coordinates 7.2.1. Example Using Geodetic Coordinates
The following is an example of mapping a service to a location using The following is an example of mapping a service to a location using
geodetic coordinates, for the service associated with the police geodetic coordinates, for the service associated with the police
(urn:service:sos.police). (urn:service:sos.police).
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1" <findService
xmlns:p2="http://www.opengis.net/gml" recursive="true" xmlns="urn:ietf:params:xml:ns:lost1"
include="uri service serviceNumber displayName serviceBoundary"> xmlns:p2="http://www.opengis.net/gml"
<location serviceBoundary="value"
profile="urn:ietf:params:lost:location-profile:geodetic-2d"> recursive="true">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>40.8089897 -73.9612492</p2:pos> <location profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point> </p2:Point>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 2: A <findService> Geodetic Query Figure 2: A <findService> geodetic query
Given the query above, a server would respond with a service, and Given the query above, a server would respond with a service, and
information related to that service. In the example below, the information related to that service. In the example below, the
server has mapped the location given by the client for a police server has mapped the location given by the client for a police
service to the New York City Police Deparment, instructing the client service to the New York City Police Deparment, instructing the client
that it may contact them via the URIs sip:nypd@example.com and that it may contact them via the URIs "sip:nypd@example.com" and
xmpp:nypd@example.com. The server has also given the client a "xmpp:nypd@example.com". The server has also given the client a
geodetic, two-dimensional boundary for this service and time-to-live geodetic, two-dimensional boundary for this service. The mapping was
value of 3,600 seconds. This instructs the client that if its last updated on November 1, 2006 and expires on January 1, 2007.
location changes beyond the give service boundary or if 3,600 seconds This instructs the client that if its location changes beyond the
has elapsed, it would need to requery for this information. give service boundary or the expiration time has been reached, it
would need to requery for this information.
<?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" timeToLive="3600"> xmlns:p2="http://www.opengis.net/gml">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">
<displayName xml:lang="en"> <displayName xml:lang="en">
New York City Police Department New York City Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary <serviceBoundary profile="geodetic-2d">
profile="urn:ietf:params:lost:location-profile:geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <p2:exterior>
<p2:LinearRing> <p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing> </p2:LinearRing>
</p2:exterior> </p2:exterior>
</p2:Polygon> </p2:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:nypd@example.com</uri> <uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="lost:authoritative.example"/>
<via source="lost:resolver.example"/>
</path>
</findServiceResponse> </findServiceResponse>
Figure 3: A <findServiceResponse> Geodetic Answer Figure 3: A <findServiceResponse> geodetic answer
6.2.2. Civic Address Mapping Example 7.2.2. Civic Address Mapping Example
The following is an example of mapping a service to a location much The following is an example of mapping a service to a location much
like the example in Section 6.2.1, but using civic address location like the example in Section 7.2.1, but using civic address location
information. In this example, the client requests the service information. In this example, the client requests the service
associated with police (urn:service:sos.police) along with a specific associated with police (urn:service:sos.police) along with a specific
civic address (house number 96 on a street named Neu Perlach in civic address (house number 6 on a street named Otto-Hahn-Ring in
Munich, Germany). Munich, Germany).
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1" <findService xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true" recursive="true" serviceBoundary="value">
include="uri serviceNumber displayName serviceBoundary" >
<location <location
profile="urn:ietf:params:lost:location-profile:basic-civic"> profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country> <country>Germany</country>
<A1>Bavaria</A1> <A1>Bavaria</A1>
<A3>Munich</A3> <A3>Munich</A3>
<A6>Neu Perlach</A6> <A6>Otto-Hahn-Ring</A6>
<HNO>96</HNO> <HNO>6</HNO>
<PC>81675</PC> <PC>81675</PC>
</civicAddress> </civicAddress>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 4: A <findService> Civic Address Query Figure 4: A <findService> civic address 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 M&#557;nchen Polizei-Abteilung, instructing the client service to the Muenchen Polizei-Abteilung, instructing the client
that it may contact them via the URIs sip:munich-police@example.com that it may contact them via the URIs sip:munich-police@example.com
and xmpp:munich-police@example.com. The server has also given the and xmpp:munich-police@example.com. The server has also given the
client a civic address boundary (the city of Munich) for this service client a civic address boundary (the city of Munich) for this
and time-to-live value of 3,600 seconds. This instructs the client service. The mapping was last updated on November 1, 2006 by the
that if its location changes beyond the give service boundary (i.e. authoritative source "lost:polizei.muenchen.de.example" and expires
beyond the city of Munich) or if 3,600 seconds has elapsed, it would on January 1, 2007. This instructs the client to requery for the
need to requery for this information. information if its location changes beyond the given service boundary
(i.e., beyond the city of Munich) or after January 1, 2007.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600"> <mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="lost:esgw.ueber-110.de.example"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109" version="1" >
<displayName xml:lang="de"> <displayName xml:lang="de">
M&#557;nchen Polizei-Abteilung Muenchen Polizei-Abteilung
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary <serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic"> profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country> <country>Germany</country>
<A1>Bavaria</A1> <A1>Bavaria</A1>
<A3>Munich</A3> <A3>Munich</A3>
<PC>81675</PC> <PC>81675</PC>
</civicAddress> </civicAddress>
</serviceBoundary> </serviceBoundary>
<uri>sip:munich-police@example.com</uri> <uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber> <serviceNumber>110</serviceNumber>
</mapping>
<path>
<via source="lost:esgw.ueber-110.de.example"/>
<via source="lost:polizei.muenchen.de.example"/>
</path>
</findServiceResponse> </findServiceResponse>
Figure 5: A <findServiceResponse> Civic Address Answer Figure 5: A <findServiceResponse> civic address answer
6.3. Components of <findService> Request 7.3. Components of the <findService> Request
6.3.1. The <location> Element The <findService> request includes attributes that govern whether the
request is handled iteratively or recursively, whether location
validation is performed and which elements must be contained in the
response.
7.3.1. The <location> Element
The <findService> query communicates location using one or more The <findService> query communicates location using one or more
<location> elements, which MUST conform to a location profile <location> elements, which MUST conform to a location profile (see
(Section 9). Section 11). There MUST be no more than one location element for
each distinct location profile. The order of location objects is
significant; the server uses the first location object where it
understands the location profile.
6.3.2. 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 [10].
6.3.3. Recursion or Redirection 7.3.3. Recursion
LoST <findService> queries can be recursive or iterative, as
indicated by the 'recursive' attribute. A value of "true" indicates
a recursive query, a value of "false" an iterative query, with
iterative being the default. When the LoST server cannot answer the
query and the query requested iterative resolution, it will return an
<iterativeSearchExhausted> (Section 10.3) error message with the LoST
URI pointing to a different LoST server that the LoST client should
contact. In recursive mode, the LoST server initiates a query and
returns the result to the original querier, inserting a <via> element
to track the response chain.
6.3.4. Configuring the Response
The 'include' attribute enumerates all the XML elements that the
client wants the LoST server to provide in the mapping response. The
server ignores any element names that it does not understand. The
ordering of the tokens is immaterial.
Among other features, it determines whether service boundaries are
returned and whether they are returned by value or reference
Section 7, and whether to validate civic locations.
Address validation is requested by including the XML element names
that provide address validation in the 'include' attribute, namely
'valid', 'invalid' and 'unchecked'. The following example
demonstrates address validation.
C: <?xml version="1.0" encoding="UTF-8"?> LoST <findService> and <listServicesByLocation> queries can be
C: <findService recursive, as indicated by the 'recursive' attribute. A value of
C: xmlns="urn:ietf:params:xml:ns:lost1" "true" indicates a recursive query, with the default being "false"
C: recursive="true" when the attribute is omitted. In recursive mode, the LoST server
C: include="uri serviceNumber invalid valid unchecked"> initiates queries on behalf of the requester and returns the result
C: <location to the requester, inserting a <via> element to track the response
C: profile="urn:ietf:params:lost:location-profile:basic-civic"> chain. The <via> elements are appended in responses in order of
C: <civicAddress visit, i.e., the first <via> element contains the authoritative
C: xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> server and <via> elements below indicate servers that the response
C: <country>Germany</country> traversed on its way back to the original querier.
C: <A1>Bavaria</A1>
C: <A3>Munich</A3>
C: <A6>Neu Perlach</A6>
C: <HNO>96</HNO>
C: <PC>81675</PC>
C: </civicAddress>
C: </location>
C: <service>urn:service:sos.police</service>
C: </findService>
S: <?xml version="1.0" encoding="UTF-8"?> 7.3.4. Service Boundary
S: <findServiceResponse
S: xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600">
S: <displayName xml:lang="de">
S: M&#557;nchen Polizei-Abteilung
S: </displayName>
S: <service>urn:service:sos.police</service>
S: <serviceBoundary
S: profile="urn:ietf:params:lost:location-profile:basic-civic">
S: <civicAddress
S: xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
S: <country>Germany</country>
S: <A1>Bavaria</A1>
S: <A3>Munich</A3>
S: <PC>81675</PC>
S: </civicAddress>
S: </serviceBoundary>
S: <uri>sip:munich-police@example.com</uri>
S: <uri>xmpp:munich-police@example.com</uri>
S: <serviceNumber>110</serviceNumber>
S: <valid>country A1 A3 A6</valid>
S: <invalid>PC</invalid>
S: </findServiceResponse>
Figure 6: Address Validation Exchange LoST <mapping> elements can describe the service boundary either by
value or by reference. Returning a service boundary reference is
generally more space-efficient for geospatial (polygon) boundaries
and if the boundaries change rarely, but does incur an additional
<getServiceBoundary> request. The querier can express a preference
for one or the other modality with the 'serviceBoundary' attribute in
the <findService> request, but the server makes the final decision as
to whether to return a reference or a value. Servers SHOULD NOT
return a by-value service boundaries if the querier requested a
reference.
6.4. Components of the Mapping Response <findServiceResponse> 7.3.5. Requesting Civic Location Validation
6.4.1. Source of Response: <via> Element Civic address validation is requested by setting the optional
attribute 'validateLocation' to true. If the attribute is omitted,
it is assumed to be false. The response is described in
Section 7.4.2. The example in Figure 6 demonstrates address
validation, omitting the standard response elements.
A <findServiceResponse> indicates the source of the response by <?xml version="1.0" encoding="UTF-8"?>
including a <via> element with a LoST URL as the first <via> element. <findService
Thus, each server "initials" its own response. Thus, responses to xmlns="urn:ietf:params:xml:ns:lost1"
iterative queries contain one <via> element, while responses to recursive="true"
recursive queries may reach the original querier with multiple <via> validateLocation="true"
elements, one for each server that was used in the resolution. The serviceBoundary="value">
following <findServiceResponse> example illustrates the use of <via>: <location profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
<PC>81675</PC>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 6: A <findService> query with address validation request
<?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" timeToLive="3600"> <mapping
<via>lost:esgw.uber-110.de.example</via> expires="2007-01-01T01:44:33Z"
<via>lost:polizei.munchen.de.example</via> lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example"
sourceId="4db898df52b84edfa9b6445ea8a0328e"
version="1" >
<displayName xml:lang="de"> <displayName xml:lang="de">
M&#557;nchen Polizei-Abteilung Muenchen Polizei-Abteilung
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary <serviceBoundary profile="civic">
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country> <country>Germany</country>
<A1>Bavaria</A1> <A1>Bavaria</A1>
<A3>Munich</A3> <A3>Munich</A3>
<PC>81675</PC> <PC>81675</PC>
</civicAddress> </civicAddress>
</serviceBoundary> </serviceBoundary>
<uri>sip:munich-police@example.com</uri> <uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber> <serviceNumber>110</serviceNumber>
</mapping>
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
</locationValidation>
<path>
<via source="lost:authoritative.example"/>
<via source="lost:resolver.example"/>
</path>
</findServiceResponse> </findServiceResponse>
Figure 7: An Example of a Response Using <via> Figure 7: A <findServiceResponse> message with address validation
information
The example above indicates that the this answer was given to the
responding server by the LoST server at esgw.uber-110.de.example,
which got the answer from the LoST server at
polizei.munchen.de.example.
6.4.2. Service URLs: the <uri> Element
The response returns the service URLs in one or more <uri> elements.
The URLs MUST be absolute URLs.
6.4.3. Describing the Service with the <displayName> Element
The <displayName> element describes the service with a string that is
suitable for display to human users, annotated with the 'xml:lang'
attribute that contains a language tag to aid in the rendering of
text.
6.4.4. Approximating Services: the <service> Element
If the requested service, identified by the service URN [10] in the
<service> element in the request, does not exist for the location
indicated, the server can either return an <serviceNotImplemented>
(Section 10.2) error or can provide an alternate service that
approximates the desired service for that location. In the latter
case, the server MUST include a <service> element with the
alternative service URN. The choice of service URN is left to local
policy, but the alternate service should be able to satisfy the
original service request.
6.4.5. Defining the Service Region with the <serviceBoundary> Element
A response can indicate the region for which the service URL returned
would be the same as in the actual query, the so-called service
region. The service region can be indicated by value or by reference
Section 6.4.6. If a client moves outside the service area, it MUST
send a new query with its current location to obtain valid service
data. The service region is described by value in one or more
<serviceBoundary> elements, each formatted according to a different
location profile. The client only processes the first element that
it can understand according to its list of supported location
profiles. Thus, the elements are alternative descriptions of the
same service region, not additive geometries.
The server returns all suitable service regions, using all available
location profiles, so that intermediate caches have this information
available for future queries.
6.4.6. Service Boundaries by Reference: the <serviceBoundaryReference>
Element
Since geodetic service boundaries may contain thousands of points and
thus be quite large, clients may opt to conserve bandwidth and
request a reference to the service boundary instead of the value
described in Section 6.4.5. The identifier of the service boundary
is returned in the <serviceBoundaryReference> element, along with a
LoST URL identifying the server from where it can be retrieved. The
actual value of the service boundary is then retrieved with the
getServiceBoundary (Section 7) request.
The identifier is a random token with at least 128 bits of entropy 7.4. Components of the Mapping Response <findServiceResponse>
and can be assumed to be globally unique. The identifier uniquely
references a particular boundary; if the boundary changes, a new
identifier must be chosen. Because of these properties, a client
receiving a mapping response can simply check if it already has a
copy of the boundary with that identifier. If so, it can skip
checking with the server whether the boundary has been updated.
Since service boundaries are likely to remain unchanged for extended
periods of time, possibly exceeding the normal lifetime of the
service URL, this approach avoids refreshing the boundary information
even if the cached service response has gotten stale.
6.4.7. The Service Number 7.4.1. Overview
The service number is returned in the optional <serviceNumber> Mapping responses consist of the <mapping> element (Section 5)
element. It contains a string of digits, * and # that a user on a describing the mapping itself, possibly followed by warnings
device with a 12-key dial pad could use to reach that particular (Section 12.2), location validation information (Section 7.4.2), and
service. an indication of the path (Section 6) the response has taken.
6.4.8. Civic Address Validation 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. Each element contains a list of has checked and found to be invalid. The server MUST include this
tokens separated by white space, enumerating the civic location information if the 'validateLocation' attribute in the request was
lables used in child elements of the <civicAddress> element. The true. Each element contains a list of tokens separated by white
<valid> element enumerates those civic address elements that have space, enumerating the civic location lables used in child elements
been recognized as valid by the LoST server and that have been used of the <civicAddress> element. The <valid> element enumerates those
to determine the mapping. The <unchecked> elements enumerates the civic address elements that have been recognized as valid by the LoST
civic address elements that the server did not check and that were server and that have been used to determine the mapping. The
not used in determining the response. The <invalid> element <unchecked> elements enumerates the civic address elements that the
enumerate civic address elements that the server attempted to check, server did not check and that were not used in determining the
but that did not match the other civic address elements found in the response. The <invalid> element enumerate civic address elements
<valid> list. that the server attempted to check, but that did not match the other
civic address elements found in the <valid> list.
Note that the same address can yield different responses if parts of
the civic address contradict each other. For example, if the postal
code does not match the city, local server policy determines whether
the postal code or the city is considered valid. The mapping
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.
6.4.9. Validity: The 'timeToLive' Attribute 8. Retrieving the Service Boundary via <getServiceBoundary>
The timeToLive attribute contains the number of seconds the response
is to be considered valid. The contents of this attribute is a
positive integer. See Section 4 regarding how this value is to be
utilized with a cache. [TBD: This could also be an absolute time.]
7. Retrieving the Service Boundary via <getServiceBoundary>
As discussed in Section 6.4.5, the <findService> response can return As discussed in Section 5.6, the <findServiceResponse> can return a
a globally unique identifier that can be used to retrieve the service globally unique identifier in the 'serviceBoundary' attribute that
boundary, rather than returning the boundary by value. This is shown can be used to retrieve the service boundary, rather than returning
in the example in Figure 8. The client can then retrieve the the boundary by value. This is shown in the example in Figure 8.
boundary using the <getServiceBoundary> request and obtains the The client can then retrieve the boundary using the
boundary in the <getServiceBoundaryResponse>, illustrated in the <getServiceBoundary> request and obtains the boundary in the
example in Section 7. The client issues the request to the server <getServiceBoundaryResponse>, illustrated in the example in
identified in the 'server' attribute of the Figure 10. The client issues the request to the server identified in
<serviceBoundaryReference> element. the 'server' attribute of the <serviceBoundaryReference> element.
These requests are always directed to the authoritative server and do
not recurse.
C: <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
C: <findService xmlns="urn:ietf:params:xml:ns:lost1" <findService
C: xmlns:p2="http://www.opengis.net/gml" recursive="true" xmlns="urn:ietf:params:xml:ns:lost1"
C: include="uri service serviceNumber displayName xmlns:p2="http://www.opengis.net/gml"
C: serviceBoundaryReference"> recursive="true"
C: <location serviceBoundary="reference">
C: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> <location profile="geodetic-2d">
C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
C: <p2:pos>40.809 -73.9612</p2:pos> <p2:pos>37.775 -122.422</p2:pos>
C: </p2:Point> </p2:Point>
C: </location> </location>
C: <service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
C: </findService> </findService>
S: <?xml version="1.0" encoding="UTF-8"?> Figure 8: <findService> request and response with service boundary
S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" reference
S: timeToLive="3600"> <?xml version="1.0" encoding="UTF-8"?>
S: <displayName xml:lang="en"> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
S: New York City Police Department xmlns:p2="http://www.opengis.net/gml">
S: </displayName> <mapping
S: <service>urn:service:sos.police</service> expires="2007-01-01T01:44:33Z"
S: <serviceBoundaryReference server="lost:nypd.example.com" lastUpdated="2006-11-01T01:00:00Z"
S: key="7214148E0433AFE2FA2D48003D31172E"/> source="lost:authoritative.example"
S: <uri>sip:nypd@example.com</uri> sourceId="7e3f40b098c711dbb6060800200c9a66"
S: <uri>xmpp:nypd@example.com</uri> version="1">
S: <serviceNumber>911</serviceNumber> <displayName xml:lang="en">
S: </findServiceResponse> New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundaryReference
source="lost:authoritative.example"
key="7214148E0433AFE2FA2D48003D31172E" />
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="lost:authoritative.example"/>
<via source="lost:resolver.example"/>
</path>
</findServiceResponse>
Figure 8: findService with Service Boundary Reference Figure 9: <findServiceResponse> message with service boundary
C: <?xml version="1.0" encoding="UTF-8"?> reference
C: <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
C: key="7214148E0433AFE2FA2D48003D31172E"/>
S: <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
S: <getServiceBoundaryResponse <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
S: xmlns="urn:ietf:params:xml:ns:lost1" key="7214148E0433AFE2FA2D48003D31172E"/>
S: xmlns:p2="http://www.opengis.net/gml">
S:
S: <serviceBoundary
S: profile="urn:ietf:params:lost:location-profile:geodetic-2d">
S: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
S: <p2:exterior>
S: <p2:LinearRing>
S: <p2:pos>40.701 -74.020</p2:pos>
S: <p2:pos>40.876 -73.926</p2:pos>
S: <p2:pos>40.797 -73.936</p2:pos>
S: <p2:pos>40.714 -73.984</p2:pos>
S: <p2:pos>40.701 -74.020</p2:pos>
S: </p2:LinearRing>
S: </p2:exterior>
S: </p2:Polygon>
S: </serviceBoundary>
S:
S: </getServiceBoundaryResponse>
Figure 9: Requesting a Service Boundary with getServiceBoundary Figure 10: Requesting a service boundary with <getServiceBoundary>
The <getServiceBoundary> request may also be used to retrieve service The <getServiceBoundary> request may also be used to retrieve service
boundaries that are expressed as civic addresses, as illustrated in boundaries that are expressed as civic addresses, as illustrated in
Figure 10. 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="urn:ietf:params:lost:location-profile:basic-civic"> profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>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>
<via source="lost:authoritative.example"/>
<via source="lost:resolver.example"/>
</path>
</getServiceBoundaryResponse> </getServiceBoundaryResponse>
Figure 10: Civic Address Service Boundary Response Figure 11: Civic Address Service Boundary Response
8. List Services: <listServices> 9. List Services: <listServices>
A LoST client can ask a LoST server for the list of services it A LoST client can ask a LoST server for the list of services that it
supports. The <listServices> query contains one or more <location> understands, primarily for diagnostic purposes. The query does not
elements, each from a different location profile (Section 9), and may contain location information, as it simply provides an indication of
contain the <service> element. If the query contains the <service> which services the server can look up, not whether a particular
element the LoST server returns only immediate child services of the service is offered for a particular area. Typically, only top-level
queried service that are available for the provided location. If the services are included in the answer, implying support for all sub-
<service> element is absent, the LoST service returns all top-level services. Since the query is answered by the queried server, there
services available for the provided location that it knows about. is no notion of recursion or indirection and no path indication. The
<listServicesByLocation (Section 10) query below can be used to find
out whether a particular service is offered for a specific location.
An example request and response are shown in Figure 12.
A server responds to this query with a <listServicesResponse> <?xml version="1.0" encoding="UTF-8"?>
response. This response has may contain <via> elements <listServices
(Section 6.4.1) and must contain a <serviceList> element, consisting xmlns="urn:ietf:params:xml:ns:lost1">
of a whitespace-separated list of service URNs. The query and <service>urn:service:sos</service>
response are illustrated in Figure 11. </listServices>
C: <?xml version="1.0" encoding="UTF-8"?> Figure 12: Example of <ListServices> query
C: <listServices
C: xmlns="urn:ietf:params:xml:ns:lost1"
C: xmlns:p2="http://www.opengis.net/gml"
C: recursive="false">
C: <location
C: profile="urn:ietf:params:lost:location-profile:basic-civic">
C: <p2:Point id="point1" srsName="epsg:4326">
C: <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates>
C: </p2:Point>
C: </location>
C: <service>urn:service:sos</service>
C: </listServices>
S: <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
S: <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1"> <listServicesResponse
S: <serviceList> xmlns="urn:ietf:params:xml:ns:lost1">
S: urn:service:sos.ambulance <serviceList>
S: urn:service:sos.animal-control urn:service:sos.ambulance
S: urn:service:sos.fire urn:service:sos.animal-control
S: urn:service:sos.gas urn:service:sos.fire
S: urn:service:sos.mountain urn:service:sos.gas
S: urn:service:sos.marine urn:service:sos.mountain
S: urn:service:sos.physician urn:service:sos.marine
S: urn:service:sos.poison urn:service:sos.physician
S: urn:service:sos.police urn:service:sos.poison
S: urn:service:sos.suicide urn:service:sos.police
S: </serviceList> urn:service:sos.suicide
S: </listServicesResponse> </serviceList>
Figure 11: ListService Query Example </listServicesResponse>
9. Location Profiles Figure 13: Example of <ListServiceResponse>
Currently, LoST uses location information in <location> elements in 10. List Services By Location: <listServicesByLocation>
requests and <serviceBoundary> elements in responses. Such location
information may be expressed in a variety of ways. This variety can
cause interoperability problems where a request or response contains
location information in a format not understood by the server or
client, respectively. To achieve interoperability, LoST defines two
must-implement baseline location profiles to define the manner in
which location information is transmitted and makes it possible to
standardize other profiles in the future. The two baseline profiles
are:
geodetic-2d: a simple profile for two-dimensional geodetic location A LoST client can ask a LoST server for the list of services it knows
information, described in Section 9.2); about for a particular area. The <listServicesByLocation> query
contains one or more <location> elements, each from a different
location profile (Section 11), and may contain the <service> element.
As for <findService>, the server selects the first location element
that has a profile the server understands and it can operate either
recursively or iteratively; < via> elements track the progress of the
request. By its nature, the query can only indicate the services
that a particular server can determine, not all possible services
that might be offered. Unlike <ListServices>, the answer describes
the services available at a specific location, not just those
understood by the server.
civic: a profile consisting of civic address location information, If the query contains the <service> element, the LoST server returns
described in Section 9.3. only immediate child services of the queried service that are
available for the provided location. If the <service> element is
absent, the LoST service returns all top-level services available for
the provided location that it knows about.
A server responds to this query with a
<listServicesByLocationResponse> response. This response MAY contain
<via> elements (see Section 6) and MUST contain a <serviceList>
element, consisting of a whitespace-separated list of service URNs.
The query and response are illustrated in Figure 14 and in Figure 15,
respectively.
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
recursive="true">
<location profile="geodetic-2d">
<p2:Point id="point1" srsName="epsg:4326">
<p2:coordinates>37:46:30N 122:25:10W</p2:coordinates>
</p2:Point>
</location>
<service>urn:service:sos</service>
</listServicesByLocation>
Figure 14: Example of <ListServicesbyLocation> query
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.animal-control
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.marine
urn:service:sos.physician
urn:service:sos.poison
urn:service:sos.police
urn:service:sos.suicide
</serviceList>
<path>
<via source="lost:authoritative.example"/>
<via source="lost:resolver.example"/>
</path>
</listServicesByLocationResponse>
Figure 15: Example of <ListServices> response
11. Location Profiles
LoST uses location information in <location> elements in requests and
<serviceBoundary> elements in responses. Such location information
may be expressed in a variety of ways. This variety can cause
interoperability problems where a request or response contains
location information in a format not understood by the server or the
client, respectively. To achieve interoperability, this document
defines two mandatory-to-implement baseline location profiles to
define the manner in which location information is transmitted. It
possible to standardize other profiles in the future. The two
baseline profiles are:
geodetic-2d:
a simple profile for two-dimensional geodetic location
information, as described in Section 11.2;
civic:
a profile consisting of civic address location information, as
described in Section 11.3.
Requests and responses containing <location> or <serviceBoundary> Requests and responses containing <location> or <serviceBoundary>
elements MUST contain location information in exactly one of the two elements MUST contain location information in exactly one of the two
baseline profiles, in addition to zero or more additional profiles. baseline profiles, in addition to zero or more additional profiles.
The ordering of location information indicates a preference on the The ordering of location information indicates a preference on the
part of the sender. part of the sender.
Standards action may create other profiles. A location profile MUST Standards action is required for defining new profiles. A location
define: profile MUST define:
1. The token identifying it in the LoST location profile registry; 1. The token identifying it in the LoST location profile registry;
2. The formal definition of the XML to be used in requests, i.e., an 2. The formal definition of the XML to be used in requests, i.e., an
enumeration and definition of the XML child elements of the enumeration and definition of the XML child elements of the
<location> element; <location> element;
3. The formal definition of the XML to be used in responses, i.e., 3. The formal definition of the XML to be used in responses, i.e.,
an enumeration and definition of the XML child elements of the an enumeration and definition of the XML child elements of the
the <serviceBoundary> element; <serviceBoundary> element;
4. The declaration of whether geodetic-2d or civic is to be used as 4. The declaration of whether geodetic-2d or civic is to be used as
the baseline profile. It is necessary to explicitly declare the the baseline profile. It is necessary to explicitly declare the
baseline profile as future profiles may be combinations of baseline profile as future profiles may be combinations of
geodetic and civic location information. geodetic and civic location information.
9.1. Location Profile Usage 11.1. Location Profile Usage
A location profile is identified by a URN in the A location profile is identified by a token in an IANA-maintained
urn:ietf:params:lost:location-profile registry. (Note that this is registry (Section 16.6). Clients send location information compliant
not an XML schema or namespace identifier.) Clients send location with a location profile, and servers respond with location
information compliant with a location profile, and servers respond information compliant with that same location profile.
with location information compliant with that same location profile.
When a LoST client sends a request which provides location When a LoST client sends a <findService> request that provides
information, it contains one or more <location> elements. Each of location information, it includes one or more <location> elements.
these elements contains location information compliant with a Each of these elements contains location information compliant with a
location profile and specifies which profile has been used in the location profile and specifies which profile has been used in the
'profile' attribute. This allows the client to convey location 'profile' attribute. This allows the client to convey location
information for multiple location profiles in the same request. information for multiple location profiles in the same request.
When a LoST server sends a response which contains location When a LoST server sends a response that contains location
information, it uses the <serviceBoundary> elements much like the information, it uses the <serviceBoundary> elements much like the
client uses the <location> elements. Each <serviceBoundary> element client uses the <location> elements. Each <serviceBoundary> element
contains location information conformant to the location profile contains location information conformant to the location profile
specified in the 'profile' attribute. This allows the server to send specified in the 'profile' attribute. This allows the server to send
location information compliant with multiple location profiles. location information compliant with multiple location profiles.
Using the location profiles defined in this document, the following Using the location profiles defined in this document, the following
rules insure basic interoperatiblity between clients and servers: rules insure basic interoperatiblity between clients and servers:
1. A client MUST be capable of understanding the response for the 1. A client MUST be capable of understanding the response for the
baseline profiles it used in the request. baseline profiles it used in the request.
2. If a client sends location information conformant to any location 2. If a client sends location information conformant to any location
profile other than geodetic-2d or civic, it MUST also send, in profile other than 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. Servers MUST implement the geodetic-2d and civic profiles. 3. There can only be one instance of each location profile in a
query.
4. A server ignores any location information using non-baseline 4. Servers MUST implement the geodetic-2d and civic profiles.
profiles it does not understand.
5. If a server receives a request that only contains location 5. A server uses the first-listed location profile that it
understands and ignores the others.
6. 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 10.2). responds with a <locationProfileError> (Section 12.1).
7. The <serviceBoundary> element MUST use the same location profile
that was used to retrieve the answer and indicates which profile
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
will still be able to understand the request and provide an will still be able to understand the request and provide an
understandable response, though with location information that might understandable response, though with location information that might
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. The both Client X and Server Y understand the baseline profile.
following transaction, where the XML sent by the client is prepended
with 'C:' and the XML sent by the server is prepended with 'S:',
demonstrates this:
C: <?xml version="1.0" encoding="UTF-8"?>
C: <findService xmlns="urn:ietf:params:xml:ns:lost1"
C: xmlns:p2="http://www.opengis.net/gml"
C: recursive="true" include="uri serviceNumber">
C: <location
C: profile="urn:ietf:params:lost:location-profile:geodetic-2d">
C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
C: <p2:pos>40.8089897 -73.9612492</p2:pos>
C: </p2:Point>
C: </location>
C: <location
C: profile="
C: urn:ietf:params:lost:location-profile:uber-complex-3d">
C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
C: <p2:pos>37.775 -122.422 25</p2:pos>
C: </p2:Point>
C: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
C: <p2:exterior>
C: <p2:LinearRing>
C: <p2:pos>40.80 -73.96 24</p2:pos>
C: <p2:pos>40.81 -73.95 27</p2:pos>
C: <p2:pos>40.80 -73.96 24</p2:pos>
C: </p2:LinearRing>
C: </p2:exterior>
C: </p2:Polygon>
C: </location>
C: <service>urn:service:sos.police</service>
C: </findService>
S: <?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" <findService
S: xmlns:p2="http://www.opengis.net/" timeToLive="3600"> xmlns="urn:ietf:params:xml:ns:lost1"
S: <locationProfileError xmlns:p2="http://www.opengis.net/gml"
S: unsupportedProfiles=" recursive="true"
S: urn:ietf:params:lost:location-profile:uber-complex-3d" serviceBoundary="value">
S: message="Too sophisticated for us." xml:lang="en"/> <location profile="uber-complex-3d">
S: <displayName xml:lang="en"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
S: New York City Police Department <p2:pos>37.775 -122.422</p2:pos>
S: </displayName> </p2:Point>
S: <service>urn:service:sos.police</service> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
S: <serviceBoundary <p2:exterior>
S: profile="urn:ietf:params:lost:location-profile:geodetic-2d"> <p2:LinearRing>
S: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:pos>37.775 -122.4194</p2:pos>
S: <p2:exterior> <p2:pos>37.555 -122.4194</p2:pos>
S: <p2:LinearRing> <p2:pos>37.555 -122.4264</p2:pos>
S: <p2:pos>40.701 -74.020</p2:pos> <p2:pos>37.775 -122.4264</p2:pos>
S: <p2:pos>40.876 -73.926</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
S: <p2:pos>40.797 -73.936</p2:pos> </p2:LinearRing>
S: <p2:pos>40.714 -73.984</p2:pos> </p2:exterior>
S: <p2:pos>40.701 -74.020</p2:pos> </p2:Polygon>
S: </p2:LinearRing> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
S: </p2:exterior> <p2:pos>-122.422 37.775</p2:pos>
S: </p2:Polygon> </p2:Point>
S: </serviceBoundary> </location>
S: <uri>sip:nypd@example.com</uri> <location profile="geodetic-2d">
S: </findServiceResponse> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 12: Example of a findServices query with baseline profile Figure 16: Example of a <findServices> query with baseline profile
interoperability interoperability
9.2. Two Dimensional Geodetic Profile <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example"
sourceId="cf19bbb038fb4ade95852795f045387d"
version="1">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
</mapping>
<path>
<via source="lost:authoritative.example"/>
<via source="lost:resolver.example"/>
</path>
</findServiceResponse>
Figure 17: Example of a <findServiceResponse> message with baseline
profile interoperability
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 GML [13] <position> element
within the <location> element. This is defined by the 'point2D' within the <location> element. This is defined by the 'point2D'
pattern in the LoST schema (see Section 12). pattern in the LoST schema (see Section 14).
Servers use this profile by placing a GML [13] <Polygon> element Servers use this profile by placing a GML [13] <Polygon> element
within the <serviceBoundary> element. This is defined by the within the <serviceBoundary> element. This is defined by the
'polygon' pattern in the LoST schema (see Section 12). 'polygon' pattern in the LoST schema (see Section 14).
9.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 [11], 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 [11], within the <serviceBoundary> element.
10. Error Handling 12. Errors, Warnings, and Redirects
Errors are indicated by error-specific elements. Depending on the When a LoST server cannot fulfill a request completely, it can return
nature of the error, the error element may occur along with other either an error or a warning, depending on the severity of the
response elements, indicating that the request was only partially problem. It returns an error element if no useful response can be
satisfied and that not all information in the request was processed returned for the query. It returns a <warnings> element as part of
correctly. Errors labeled as fatal means 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
elements, the 'source' attribute names the server that originally
generated the error or warning, such as the authoritative server.
Unless otherwise noted, all elements below can be either an error or
a warning, depending on whether a default response, such as a
mapping, is included.
10.1. Basic Errors 12.1. Errors
LoST defines a pattern for errors, defined as "errors" in the Relax LoST defines a pattern for errors, defined as <errors> elements in
NG schema. This pattern defines a 'message' attribute containing the Relax NG schema. This pattern defines a 'message' attribute
human readable text and an 'xml:lang' attribute denoting the language containing human readable text and an 'xml:lang' attribute denoting
of the human readable text. the language of the human readable text. One or more such error
elements are contained in the <errors> element.
LoST defines the following elements as following this pattern: The following errors follow this basic pattern:
badRequest The server could not parse or otherwise understand a badRequest
request. This is a top-level element, and is returned if the
server did not understand the outermost LoST XML element
identifying the request.
serviceSubstitution The server substituted one service for another. The server could not parse or otherwise understand a request,
See Section 6.4.4. e.g., because the XML was malformed.
10.2. Response Errors forbidden
LoST defines a pattern for errors that may generated by referrent The server refused to send an answer. This generally only occurs
LoST serves queried on behalf of seekers by a resolving LoST server. for recursive queries, namely if the resolver tried to contact the
This pattern builds on the basic errors pattern (Section 10.1). It authoritative server and was refused. (For HTTP as the underlying
also provides the option of specifying the source server using the protocol, an HTTP 401 error would be returned.)
'source' attribute, as well as specifying the query that caused the
error.
LoST defines the following elements as following this pattern: internalError
forbidden The server refused to send an answer. The server could not satisfy a request due to misconfiguration or
other operational and non-protocol related reasons.
notFound The server could not find an answer to the query. locationProfileUnrecognized
serviceNotImplemented The requested service is not implemented. None of the profiles in the request were recognized by the server
(see Section 11).
internalError The server could not satisfy a request due to loop
misconfiguration or other operational and non-protocol related
reasons.
serverTimeout A time out occurred before an answer was received. During a recursive query, the server was about to visit a server
that was already in the server list in the <path> element,
indicating a request loop.
serverError An answer was received but it could not be parsed or notFound
otherwise understood.
locationProfileError A location profile in the query given is not The server could not find an answer to the query.
recognized. The element may also have an 'unsupportedProfiles'
attribute, which contains a whitespace separated list of profile
URNs. See Section 9.
10.3. Redirects serverError
LoST defines a pattern for redirect responses. This pattern builds An answer was received from another LoST server, but it could not
on the basic error pattern (Section 10.1) and includes a 'url' be parsed or otherwise understood. This error occurs only for
attribute indicating the LoST URL that the client should be recursive queries.
contacting next.
Currently, LoST only defines the <redirect> element along this serverTimeout
pattern.
11. LoST Transport A time out occurred before an answer was received.
serviceNotImplemented
The requested service URN is not implemented and no substitution
was available.
An example is below:
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1"
source="lost:resolver.example">
<internalError message="Software bug." xml:lang="en"/>
</errors>
Figure 18: Example of an error resonse
12.2. Warnings
A response MAY contain zero or more warnings. This pattern defines a
'message' attribute containing human readable text and an 'xml:lang'
attribute denoting the language of the human readable text. One or
more such warning elements are contained in the <warnings> element.
This version of the specification does not define any warning
elements.
12.3. Redirects
A LoST server can respond indicating that the querier should redirect
the query to another server, using the <redirect> element. The
element includes a 'target' attribute indicating the LoST URL that
the client SHOULD be contacting next, as well as the 'source'
attribute indicating the server that generated the redirect response
and a 'message' attribute explaining the reason for the redirect
response. During a recursive query, a server receiving a <redirect>
response can decide whether it wants to follow the redirection or
simply return the response to its upstream querier.
An example is below:
<?xml version="1.0" encoding="UTF-8"?>
<redirect xmlns="urn:ietf:params:xml:ns:lost1"
target="lost:eastpsap.example"
source="lost:westpsap.example"
message="We have temporarily failed over." xml:lang="en"/>
Figure 19: Example of a redirect resonse
13. LoST Transport
LoST needs an underlying protocol transport mechanisms to carry LoST needs an underlying protocol transport mechanisms to carry
requests and responses. This document defines the use of LoST over requests and responses. This document defines the use of LoST over
HTTP and HTTP-over-TLS; other mechanisms are left to future HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future
documents. The available transport mechanisms are determined through documents. The available transport mechanisms are determined through
the use of the LoST U-NAPTR application. In protocols that support the use of the LoST U-NAPTR application. In protocols that support
content type indication, LoST uses the media type application/ content type indication, LoST uses the media type application/
lost+xml. lost+xml.
When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP
POST method. All HTTP responses are applicable. The HTTP URL is POST method. All HTTP responses are applicable. The HTTP URL is
derived from the LoST URL via U-NAPTR application, as discussed in derived from the LoST URL via U-NAPTR application, as discussed in
Section 5. Section 4.
12. 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" 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" 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
| listServices | listServices
| listServicesByLocation
| getServiceBoundary | getServiceBoundary
| findServiceResponse | findServiceResponse
| listServicesResponse | listServicesResponse
| listServicesByLocationResponse
| getServiceBoundaryResponse | getServiceBoundaryResponse
| errors
| redirect
## ##
## The queries. ## The queries.
## ##
div { div {
findService = findService =
element ns1:findService { element ns1:findService {
query, element ns1:location { locationInformation }+,
attribute include { commonRequestPattern,
list { attribute validateLocation {
("uri" xsd:boolean >> a:defaultValue [ "false" ]
| "serviceNumber" }?,
| "displayName" attribute serviceBoundary {
| "service" ("reference" | "value") >> a:defaultValue [ "reference" ]
| "valid" }?,
| "invalid" attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
| "unchecked"
| "serviceBoundary"
| "serviceBoundaryReference")*
} }
>> a:defaultValue [ "uri serviceNumber" ] listServices = element ns1:listServices { commonRequestPattern }
}? listServicesByLocation =
element ns1:listServicesByLocation {
element ns1:location { locationInformation }*,
commonRequestPattern,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
} }
listServices = element ns1:listServices { query }
getServiceBoundary = getServiceBoundary =
element ns1:getServiceBoundary { element ns1:getServiceBoundary {
serviceBoundaryKey, extensionPoint serviceBoundaryKey, extensionPoint
} }
} }
## ##
## The responses. ## The responses.
## ##
div { div {
findServiceResponse = findServiceResponse =
element ns1:findServiceResponse { element ns1:findServiceResponse {
via, mapping+, locationValidation?, commonResponsePattern
((locationProfileError?, serviceSubstitution?, serviceResult)
| badRequest
| internalError
| forbidden
| notFound
| serviceNotImplemented
| serverTimeout
| serverError
| movedPermenantly
| movedTemporarily
| iterativeSearchExhausted),
extensionPoint
} }
listServicesResponse = listServicesResponse =
element ns1:listServicesResponse { element ns1:listServicesResponse {
via, serviceList, commonResponsePattern
((locationProfileError?, }
element ns1:serviceList { listServicesByLocationResponse =
list { xsd:anyURI* } element ns1:listServicesByLocationResponse {
})), serviceList, commonResponsePattern
extensionPoint
} }
getServiceBoundaryResponse = getServiceBoundaryResponse =
element ns1:getServiceBoundaryResponse { element ns1:getServiceBoundaryResponse {
(serviceBoundary serviceBoundary, commonResponsePattern
| badRequest
| internalError
| forbidden
| notFound),
extensionPoint
} }
} }
## ##
## A pattern common to some of the queries. ## A pattern common to some of the queries.
## ##
div { div {
query = commonRequestPattern = service, extensionPoint
element ns1:location { locationInformation }+, }
element ns1:service { xsd:anyURI }?,
extensionPoint, ##
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? ## A pattern common to responses.
##
div {
commonResponsePattern = warnings*, path, extensionPoint
} }
## ##
## Location Information ## Location Information
## ##
div { div {
locationInformation = locationInformation =
extensionPoint+, extensionPoint+,
attribute profile { xsd:anyURI } attribute profile { xsd:NMTOKEN }
} }
## ##
## Service Boundary ## Service Boundary
## ##
div { div {
serviceBoundary = element ns1:serviceBoundary serviceBoundary = element ns1:serviceBoundary { locationInformation }+
{ locationInformation }+
} }
## ##
## Service Boundary Key ## Service Boundary Reference
## ##
div { div {
serviceBoundaryKey = serviceBoundaryReference =
attribute key { element ns1:serviceBoundaryReference {
xsd:string { pattern = "[a-zA-Z0-9/+=]+" } source, serviceBoundaryKey, extensionPoint
} }
serviceBoundaryKey = attribute key { xsd:token }
} }
## ##
## Via - list of places through which information flowed ## Path -
## Contains a list of via elements -
## places through which information flowed
## ##
div { div {
via = element ns1:via { xsd:anyURI }* path =
element ns1:path {
element ns1:via { source, extensionPoint }*
}
} }
## ##
## Time-to-live pattern ## Expires pattern
## ##
div { div {
timeToLive = attribute timeToLive { xsd:positiveInteger } expires = attribute expires { xsd:dateTime }
} }
## ##
## A QName list ## A QName list
## ##
div { div {
qnameList = list { xsd:QName* } qnameList = list { xsd:QName* }
} }
## ##
## A location-to-service result. ## A location-to-service mapping.
## ##
div { div {
serviceResult = mapping =
element ns1:mapping {
element ns1:displayName { element ns1:displayName {
xsd:string, xsd:string,
attribute xml:lang { xsd:language } attribute xml:lang { xsd:language }
}?, }*,
element ns1:service { xsd:anyURI }?, service,
(serviceBoundary (serviceBoundary | serviceBoundaryReference)?,
| element ns1:serviceBoundaryReference { serviceBoundaryKey })?,
element ns1:uri { xsd:anyURI }*, element ns1:uri { xsd:anyURI }*,
element ns1:serviceNumber { element ns1:serviceNumber {
xsd:string { pattern = "[0-9]+" } xsd:string { pattern = "[0-9*#]+" }
}?, }?,
element ns1:valid { qnameList }?,
element ns1:invalid { qnameList }?,
element ns1:unchecked { qnameList }?,
extensionPoint, extensionPoint,
timeToLive, expires,
attribute lastUpdated { xsd:dateTime },
source,
attribute sourceId { xsd:token },
attribute version { xsd:positiveInteger },
message message
} }
}
## ##
## Basic Errors ## Location validation
## ##
div { div {
locationValidation =
element ns1:locationValidation {
element ns1:valid { qnameList }?,
element ns1:invalid { qnameList }?,
element ns1:unchecked { qnameList }?,
extensionPoint
}
}
## ##
## Error pattern. ## Errors and Warnings Container.
## ##
error = message, extensionPoint div {
badRequest = element ns1:badRequest { error } errorContainer =
internalError = element ns1:internalError { error } (badRequest?
serviceSubstitution = element ns1:serviceSubstitution { error } & internalError?
& serviceSubstitution?
& forbidden?
& notFound?
& loop?
& serviceNotImplemented?
& serverTimeout?
& serverError?
& locationProfileUnrecognized?),
extensionPoint,
source
errors = element ns1:errors { errorContainer }
warnings = element ns1:warnings { errorContainer }
} }
## ##
## Recursion Errors. ## Basic Errors
## ##
div { div {
## ##
## Recursion error. ## Error pattern.
## ##
recursionError = basicError = message, extensionPoint
attribute failedReferral { xsd:anyURI }?, badRequest = element ns1:badRequest { basicError }
(findService | listServices | getServiceBoundary)?, internalError = element ns1:internalError { basicError }
error serviceSubstitution = element ns1:serviceSubstitution { basicError }
forbidden = forbidden = element ns1:forbidden { basicError }
element ns1:forbidden { recursionError }, notFound = element ns1:notFound { basicError }
timeToLive loop = element ns1:loop { basicError }
notFound =
element ns1:notFound { recursionError },
timeToLive
serviceNotImplemented = serviceNotImplemented =
element ns1:serviceNotImplemented { recursionError }, element ns1:serviceNotImplemented { basicError }
timeToLive serverTimeout = element ns1:serverTimeout { basicError }
serverTimeout = serverError = element ns1:serverError { basicError }
element ns1:serverTimeout { recursionError }, locationProfileUnrecognized =
timeToLive element ns1:locationProfileUnrecognized {
serverError = attribute unsupportedProfiles { xsd:NMTOKENS },
element ns1:serverError { recursionError }, basicError
timeToLive
locationProfileError =
element ns1:locationProfileError {
attribute unsupportedProfiles {
list { xsd:anyURI* }
},
recursionError
} }
} }
## ##
## Redirects. ## Redirect.
## ##
div { div {
## ##
## Redirect pattern ## Redirect pattern
## ##
redirect = redirect =
attribute redirect { xsd:anyURI }, element ns1:redirect {
error attribute target { xsd:anyURI },
movedPermenantly = element ns1:movedPermanently { redirect } source,
movedTemporarily = message,
element ns1:movedTemporarily { redirect }, extensionPoint
timeToLive }
iterativeSearchExhausted =
element ns1:iterativeSearchExhausted { redirect },
timeToLive
} }
## ##
## Message pattern. ## 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 }?
source = attribute source { xsd:anyURI }
serviceList =
element ns1:serviceList {
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 {
## ##
## Any element not in the LoST namespace. ## Any element not in the LoST namespace.
skipping to change at page 36, line 4 skipping to change at page 42, line 14
## 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. ## A 2D point from GML.
## ##
point2d = point2d =
element position {
element Point { element Point {
attribute srsName { "urn:ogc:def:crs:EPSG:4326" }, attribute srsName { "urn:ogc:def:crs:EPSG::4326" },
element pos { text } pos
} }
##
## A GML position
##
pos =
element pos {
list { xsd:double }
} }
## ##
## A Linear Ring from GML. ## A Linear Ring from GML.
## ##
linearRing = linearRing = element LinearRing { pos, pos, pos, pos+ }
element LinearRing {
element pos { text }
}
## ##
## A Polygon from GML. ## A Polygon from GML.
## ##
polygon = polygon =
element Polygon { element Polygon {
attribute srsName { "urn:ogc:def:crs:EPSG:4979" }, attribute srsName { "urn:ogc:def:crs:EPSG::4326" },
element exterior { linearRing }, element exterior { linearRing },
element interior { linearRing }* element interior { linearRing }*
} }
} }
13. Internationalization Considerations Figure 20: RelaxNG schema
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
the <displayName> element and the 'message' attributes may be the <displayName> element and the 'message' attributes may be
displayed to the end user, and they are thus a complex types designed displayed to the end user, and they are thus a complex types designed
for this purpose. for this purpose.
LoST exchanges information using XML. All XML processors are LoST exchanges information using XML. All XML processors are
required to understand UTF-8 and UTF-16 encodings, and therefore all required to understand UTF-8 and UTF-16 encodings, and therefore all
LoST clients and servers MUST understand UTF-8 and UTF-16 encoded LoST clients and servers MUST understand UTF-8 and UTF-16 encoded
XML. Additionally, LoST servers and clients MUST NOT encode XML with XML. Additionally, LoST servers and clients MUST NOT encode XML with
encodings other than UTF-8 or UTF-16. encodings other than UTF-8 or UTF-16.
14. IANA Considerations 16. IANA Considerations
14.1. U-NAPTR Registrations 16.1. U-NAPTR Registrations
This document registers the following U-NAPTR application service This document registers the following U-NAPTR application service
tag: tag:
Application Service Tag: LoST Application Service Tag: LoST
Defining Publication: The specification contained within this Defining Publication: The specification contained within this
document. document.
This document registers the following U-NAPTR application protocol This document registers the following U-NAPTR application protocol
skipping to change at page 38, line 32 skipping to change at page 44, line 32
Application Protocol Tag: http Application Protocol Tag: http
Defining Publication: RFC 2616 [3] Defining Publication: RFC 2616 [3]
o o
Application Protocol Tag: https Application Protocol Tag: https
Defining Publication: RFC 2818 [5] Defining Publication: RFC 2818 [5]
14.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 [9] and guidelines in RFC according to the procedures of RFC 4288 [9] and guidelines in RFC
3023 [6]. 3023 [6].
MIME media type name: application MIME media type name: application
MIME subtype name: lost+xml MIME subtype name: lost+xml
Mandatory parameters: none Mandatory parameters: none
skipping to change at page 40, line 9 skipping to change at page 46, line 9
Author: Author:
This specification is a work item of the IETF ECRIT working group, This specification is a work item of the IETF ECRIT working group,
with mailing list address <ecrit@ietf.org>. with mailing list address <ecrit@ietf.org>.
Change controller: Change controller:
The IESG <iesg@ietf.org> The IESG <iesg@ietf.org>
14.3. LoST Relax NG Schema Registration 16.3. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:lost 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 12. Its first line is in Section 14. Its first line is
default namespace = "urn:ietf:params:xml:ns:lost1" default namespace = "urn:ietf:params:xml:ns:lost1"
and its last line is and its last line is
} }
14.4. LoST Namespace Registration 16.4. LoST Namespace Registration
URI: urn:ietf:params:xml:ns:lost 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).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>LoST Namespace</title> <title>LoST Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for LoST</h1> <h1>Namespace for LoST</h1>
<h2>urn:ietf:params:xml:ns:lost</h2> <h2>urn:ietf:params:xml:ns:lost1</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR: [NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this Please replace XXXX with the RFC number of this
specification.]</a>.</p> specification.]</a>.</p>
</body> </body>
</html> </html>
END END
14.5. Registration Template 16.5. URL Registration Template
This registration template is in accordance with [4]. This registration template is in accordance with [4].
URL scheme name: URL scheme name:
lost lost
URL scheme syntax: URL scheme syntax:
See Section 5 See Section 4
Character encoding considerations: Character encoding considerations:
See Section 5 See Section 4
Intended Use: Intended Use:
The intended usage is described in this document. The intended usage is described in this document.
Application and protocols which use this scheme: Application and protocols which use this scheme:
The usage of the LoST URL scheme is targeted for this document and The usage of the LoST URL scheme is targeted for this document and
hence for location-based services that make use of the mapping hence for location-based services that make use of the mapping
protocol specified in this document. protocol specified in this document.
Interoperability considerations: Interoperability considerations:
None None
Security considerations: Security considerations:
See Section 15 See Section 17
Relevant publications: Relevant publications:
This document provides the relevant context for this URL scheme. This document provides the relevant context for this URL scheme.
Contact: Contact:
Hannes Tschofenig, Hannes.Tschofenig@siemens.com Hannes Tschofenig, Hannes.Tschofenig@siemens.com
Author/Change controller: Author/Change controller:
The IESG <iesg@ietf.org> The IESG <iesg@ietf.org>
14.6. LoST Location Profile Registry 16.6. LoST Location Profile Registry
This document seeks to create a registry of location profile names This document seeks to create a registry of location profile names
for the LoST protocol. Profile names are XML tokens. This registry for the LoST protocol. Profile names are XML tokens. This registry
will operate in accordance with RFC 2434 [2], Standards Action. will operate in accordance with RFC 2434 [2], Standards Action.
geodetic-2d: Defined in TBD geodetic-2d:
civic: Defined in TBD Defined in Section 11.2
15. Security Considerations civic:
Defined in Section 11.3
17. Security Considerations
There are multiple threats to the overall system of which service There are multiple threats to the overall system of which service
mapping forms a part. An attacker that can obtain service contact mapping forms a part. An attacker that can obtain service contact
URIs can use those URIs to attempt to disrupt those services. An URIs can use those URIs to attempt to disrupt those services. An
attacker that can prevent the lookup of contact URIs can impair the attacker that can prevent the lookup of contact URIs can impair the
reachability of such services. An attacker that can eavesdrop on the reachability of such services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an communication requesting this lookup can surmise the existence of an
emergency and possibly its nature, and may be able to use this to emergency and possibly its nature, and may be able to use this to
launch a physical attack on the caller. launch a physical attack on the caller.
To avoid that an attacker can modify the query or its result, the use To avoid that an attacker can modify the query or its result, the use
of channels security, such as TLS, is RECOMMENDED. of channels security, such as TLS, is RECOMMENDED.
A more detailed description of threats and security requirements are A more detailed description of threats and security requirements are
provided in [17]. provided in [17].
16. Acknowledgments 18. Acknowledgments
[Editor's Note: Names need to be added here. Forgot it...Sorry.] We would like to the thank the following working group members for
the detailed review of previous LoST document versions:
17. Open Issues o Barbara Stark (Review in Jan. 2007)
o Martin Thomson (Review in Dec. 2006, Review Jul. 2006)
o Shida Schubert (Review Nov. 2006)
o Leslie Daigle (Review Sep. 2006)
o Jonathan Rosenberg (Review Jul. 2006)
We would also like to thank the following working group members for
their input to selected design aspects of the LoST protocol:
o Leslie Daigle and Martin Thomson (Input to DNS-based LoST
discovery procedure)
o John Schnizlein (Authoritive LoST Answers)
o Rohan Mahy (Display Names)
o James Polk (Error Handling)
o Ron Watro and Richard Barnes (Expiry of cached data)
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James
Winterbottom (Indication of PSAP Confidence Level)
o Martin Thomson (Service Boundary references)
o Martin Thomson (Service URN in LoST response message)
o Cullen Jennings (Service Boundaries)
o Clive D.W. Feather, Martin Thomson (Validation Functionality)
o Roger Marshall (PSAP Preference in LoST response)
o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor,
Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W.
Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-
Francois Mule, Pierre Desjardins (Location Profiles)
o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson,
Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage,
Keith (List Services functionality)
o Thomson, Martin, Michael Hammer (Mapping of Services)
o Shida Schubert, James Winterbottom, Keith Drage (default service
URN)
o Otmar Lendl (LoST aggregation)
The following working group members provided miscellaneous input to
the design of the protocol:
o Klaus Darilion
o Marc Linsner
Finally, we would like to particularly thank Brian Rosen as a long
term contributor who participated in almost every discussion thread.
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/
18. References 20. References
18.1. Normative References 20.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
skipping to change at page 46, line 48 skipping to change at page 53, line 48
[10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [10] 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 [11] 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-04 (work in
progress), September 2006. progress), September 2006.
[12] Daigle, L., "Domain-based Application Service Location Using [12] Daigle, L., "Domain-based Application Service Location Using
URIs and the Dynamic Delegation Discovery Service (DDDS)", URIs and the Dynamic Delegation Discovery Service (DDDS)",
draft-daigle-unaptr-00 (work in progress), June 2006. draft-daigle-unaptr-01 (work in progress), October 2006.
[13] OpenGIS, "Open Geography Markup Language (GML) Implementation [13] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC OGC 02-023r4, January 2003. Specification", OGC OGC 02-023r4, January 2003.
18.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.
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
skipping to change at page 47, line 28 skipping to change at page 54, line 28
[17] Taylor, T., "Security Threats and Requirements for Emergency [17] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 Call Marking and Mapping", draft-ietf-ecrit-security-threats-03
(work in progress), July 2006. (work in progress), July 2006.
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-12 (work in progress), draft-ietf-ecrit-requirements-12 (work in progress),
August 2006. August 2006.
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-00 (work in Framework", draft-ietf-ecrit-mapping-arch-01 (work in
progress), August 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"
skipping to change at page 48, line 24 skipping to change at page 55, line 24
<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="getServiceBoundary" /> <ref name="getServiceBoundary" />
<ref name="findServiceResponse" /> <ref name="findServiceResponse" />
<ref name="listServicesResponse" /> <ref name="listServicesResponse" />
<ref name="listServicesByLocationResponse" />
<ref name="getServiceBoundaryResponse" /> <ref name="getServiceBoundaryResponse" />
<ref name="errors" />
<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">
<ref name="query" /> <oneOrMore>
<element name="location">
<ref name="locationInformation" />
</element>
</oneOrMore>
<ref name="commonRequestPattern" />
<optional> <optional>
<attribute name="include"> <attribute name="validateLocation">
<list> <data type="boolean" />
<zeroOrMore> <a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="serviceBoundary">
<choice> <choice>
<value>uri</value> <value>reference</value>
<value>serviceNumber</value> <value>value</value>
<value>displayName</value>
<value>service</value>
<value>valid</value>
<value>invalid</value>
<value>unchecked</value>
<value>serviceBoundary</value>
<value>serviceBoundaryReference</value>
</choice> </choice>
</zeroOrMore> <a:defaultValue>reference</a:defaultValue>
</list> </attribute>
<a:defaultValue>uri serviceNumber</a:defaultValue> </optional>
<optional>
<attribute name="recursive">
<data type="boolean" />
<a:defaultValue>true</a:defaultValue>
</attribute> </attribute>
</optional> </optional>
</element> </element>
</define> </define>
<define name="listServices"> <define name="listServices">
<element name="listServices"> <element name="listServices">
<ref name="query" /> <ref name="commonRequestPattern" />
</element>
</define>
<define name="listServicesByLocation">
<element name="listServicesByLocation">
<zeroOrMore>
<element name="location">
<ref name="locationInformation" />
</element>
</zeroOrMore>
<ref name="commonRequestPattern" />
<optional>
<attribute name="recursive">
<data type="boolean" />
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
</element> </element>
</define> </define>
<define name="getServiceBoundary"> <define name="getServiceBoundary">
<element name="getServiceBoundary"> <element name="getServiceBoundary">
<ref name="serviceBoundaryKey" /> <ref name="serviceBoundaryKey" />
<ref name="extensionPoint" /> <ref name="extensionPoint" />
</element> </element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
The responses. The responses.
</a:documentation> </a:documentation>
<define name="findServiceResponse"> <define name="findServiceResponse">
<element name="findServiceResponse "> <element name="findServiceResponse ">
<ref name="via" /> <oneOrMore>
<choice> <ref name="mapping" />
<group> </oneOrMore>
<optional>
<ref name="locationProfileError"/>
</optional>
<optional> <optional>
<ref name="serviceSubstitution"/> <ref name="locationValidation" />
</optional> </optional>
<ref name="serviceResult" /> <ref name="commonResponsePattern" />
</group>
<ref name="badRequest"/>
<ref name="internalError"/>
<ref name="forbidden"/>
<ref name="notFound"/>
<ref name="serviceNotImplemented"/>
<ref name="serverTimeout"/>
<ref name="serverError"/>
<ref name="movedPermenantly"/>
<ref name="movedTemporarily"/>
<ref name="iterativeSearchExhausted"/>
</choice>
<ref name="extensionPoint" />
</element> </element>
</define> </define>
<define name="listServicesResponse"> <define name="listServicesResponse">
<element name="listServicesResponse"> <element name="listServicesResponse">
<ref name="via" /> <ref name="serviceList" />
<choice> <ref name="commonResponsePattern" />
<group>
<optional>
<ref name="locationProfileError"/>
</optional>
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI" />
</zeroOrMore>
</list>
</element> </element>
</group> </define>
</choice>
<ref name="extensionPoint" /> <define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList" />
<ref name="commonResponsePattern" />
</element> </element>
</define> </define>
<define name="getServiceBoundaryResponse"> <define name="getServiceBoundaryResponse">
<element name="getServiceBoundaryResponse"> <element name="getServiceBoundaryResponse">
<choice>
<group>
<ref name="serviceBoundary"/> <ref name="serviceBoundary"/>
</group> <ref name="commonResponsePattern" />
<ref name="badRequest"/>
<ref name="internalError"/>
<ref name="forbidden"/>
<ref name="notFound"/>
</choice>
<ref name="extensionPoint" />
</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="query"> <define name="commonRequestPattern">
<oneOrMore> <ref name="service" />
<element name="location">
<ref name="locationInformation" />
</element>
</oneOrMore>
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
<ref name="extensionPoint" /> <ref name="extensionPoint" />
<optional>
<attribute name="recursive">
<data type="boolean" />
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
</define> </define>
</div>
<div>
<a:documentation>
A pattern common to responses.
</a:documentation>
<define name="commonResponsePattern">
<zeroOrMore>
<ref name="warnings" />
</zeroOrMore>
<ref name="path" />
<ref name="extensionPoint" />
</define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Location Information Location Information
</a:documentation> </a:documentation>
<define name="locationInformation"> <define name="locationInformation">
<oneOrMore> <oneOrMore>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
</oneOrMore> </oneOrMore>
<attribute name="profile"> <attribute name="profile">
<data type="anyURI" /> <data type="NMTOKEN" />
</attribute> </attribute>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Service Boundary Service Boundary
</a:documentation> </a:documentation>
<define name="serviceBoundary"> <define name="serviceBoundary">
<oneOrMore> <oneOrMore>
<element name="serviceBoundary"> <element name="serviceBoundary">
<ref name="locationInformation" /> <ref name="locationInformation" />
</element> </element>
</oneOrMore> </oneOrMore>
</define> </define>
</div> </div>
<div> <div>
skipping to change at page 52, line 15 skipping to change at page 59, line 11
<oneOrMore> <oneOrMore>
<element name="serviceBoundary"> <element name="serviceBoundary">
<ref name="locationInformation" /> <ref name="locationInformation" />
</element> </element>
</oneOrMore> </oneOrMore>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Service Boundary Key Service Boundary Reference
</a:documentation> </a:documentation>
<define name="serviceBoundaryReference">
<element name="serviceBoundaryReference">
<ref name="source" />
<ref name="serviceBoundaryKey" />
<ref name="extensionPoint" />
</element>
</define>
<define name="serviceBoundaryKey"> <define name="serviceBoundaryKey">
<attribute name="key"> <attribute name="key">
<data type="string"> <data type="token" />
<param name="pattern">[a-zA-Z0-9/+=]+</param>
</data>
</attribute> </attribute>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Via - list of places through which information flowed Path -
Contains a list of via elements -
places through which information flowed
</a:documentation> </a:documentation>
<define name="via"> <define name="path">
<element name="path">
<zeroOrMore> <zeroOrMore>
<element name="via"> <element name="via">
<data type="anyURI"/> <ref name="source" />
<ref name="extensionPoint" />
</element> </element>
</zeroOrMore> </zeroOrMore>
</element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Time-to-live pattern Expires pattern
</a:documentation> </a:documentation>
<define name="timeToLive"> <define name="expires">
<attribute name="timeToLive"> <attribute name="expires">
<data type="positiveInteger"/> <data type="dateTime"/>
</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">
<list> <list>
<zeroOrMore> <zeroOrMore>
<data type="QName"/> <data type="QName"/>
</zeroOrMore> </zeroOrMore>
skipping to change at page 53, line 20 skipping to change at page 60, line 30
<list> <list>
<zeroOrMore> <zeroOrMore>
<data type="QName"/> <data type="QName"/>
</zeroOrMore> </zeroOrMore>
</list> </list>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
A location-to-service result. A location-to-service mapping.
</a:documentation> </a:documentation>
<define name="serviceResult"> <define name="mapping">
<optional> <element name="mapping">
<zeroOrMore>
<element name="displayName"> <element name="displayName">
<data type="string"/> <data type="string"/>
<attribute name="xml:lang"> <attribute name="xml:lang">
<data type="language"/> <data type="language"/>
</attribute> </attribute>
</element> </element>
</optional> </zeroOrMore>
<optional> <ref name="service" />
<element name="service">
<data type="anyURI"/>
</element>
</optional>
<optional> <optional>
<choice> <choice>
<ref name="serviceBoundary"/> <ref name="serviceBoundary"/>
<element name="serviceBoundaryReference"> <ref name="serviceBoundaryReference"/>
<ref name="serviceBoundaryKey"/>
</element>
</choice> </choice>
</optional> </optional>
<zeroOrMore> <zeroOrMore>
<element name="uri"> <element name="uri">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<optional> <optional>
<element name="serviceNumber"> <element name="serviceNumber">
<data type="string"> <data type="string">
<param name="pattern">[0-9]+</param> <param name="pattern">[0-9*#]+</param>
</data> </data>
</element> </element>
</optional> </optional>
<ref name="extensionPoint"/>
<ref name="expires"/>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<ref name="source" />
<attribute name="sourceId">
<data type="token" />
</attribute>
<attribute name="version">
<data type="positiveInteger" />
</attribute>
<ref name="message"/>
</element>
</define>
</div>
<div>
<a:documentation>
Location validation
</a:documentation>
<define name="locationValidation">
<element name="locationValidation">
<optional> <optional>
<element name="valid"> <element name="valid">
<ref name="qnameList" /> <ref name="qnameList" />
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="invalid"> <element name="invalid">
<ref name="qnameList" /> <ref name="qnameList" />
</element> </element>
</optional> </optional>
<optional> <optional>
<element name="unchecked"> <element name="unchecked">
<ref name="qnameList" /> <ref name="qnameList" />
</element> </element>
</optional> </optional>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
<ref name="timeToLive"/> </element>
<ref name="message"/> </define>
</div>
<div>
<a:documentation>
Errors and Warnings Container.
</a:documentation>
<define name="errorContainer">
<interleave>
<optional>
<ref name="badRequest" />
</optional>
<optional>
<ref name="internalError" />
</optional>
<optional>
<ref name="serviceSubstitution" />
</optional>
<optional>
<ref name="forbidden" />
</optional>
<optional>
<ref name="notFound" />
</optional>
<optional>
<ref name="loop" />
</optional>
<optional>
<ref name="serviceNotImplemented" />
</optional>
<optional>
<ref name="serverTimeout" />
</optional>
<optional>
<ref name="serverError" />
</optional>
<optional>
<ref name="locationProfileUnrecognized" />
</optional>
</interleave>
<ref name="extensionPoint" />
<ref name="source" />
</define>
<define name="errors">
<element name="errors">
<ref name="errorContainer" />
</element>
</define>
<define name="warnings">
<element name="warnings">
<ref name="errorContainer" />
</element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Basic Errors Basic Errors
</a:documentation> </a:documentation>
<define name="error"> <define name="basicError">
<a:documentation> <a:documentation>
Error pattern. Error pattern.
</a:documentation> </a:documentation>
<ref name="message"/> <ref name="message"/>
<ref name="extensionPoint" /> <ref name="extensionPoint" />
</define> </define>
<define name="badRequest"> <define name="badRequest">
<element name="badRequest"> <element name="badRequest">
<ref name="error"/> <ref name="basicError"/>
</element> </element>
</define> </define>
<define name="internalError"> <define name="internalError">
<element name="internalError"> <element name="internalError">
<ref name="error"/> <ref name="basicError"/>
</element> </element>
</define> </define>
<define name="serviceSubstitution"> <define name="serviceSubstitution">
<element name="serviceSubstitution"> <element name="serviceSubstitution">
<ref name="error"/> <ref name="basicError"/>
</element> </element>
</define> </define>
</div>
<div>
<a:documentation>
Recursion Errors.
</a:documentation>
<define name="recursionError">
<a:documentation>
Recursion error.
</a:documentation>
<optional>
<attribute name="failedReferral">
<data type="anyURI"/>
</attribute>
</optional>
<optional>
<choice>
<ref name="findService" />
<ref name="listServices" />
<ref name="getServiceBoundary" />
</choice>
</optional>
<ref name="error"/>
</define>
<define name="forbidden"> <define name="forbidden">
<element name="forbidden"> <element name="forbidden">
<ref name="recursionError"/> <ref name="basicError"/>
</element> </element>
<ref name="timeToLive"/>
</define> </define>
<define name="notFound"> <define name="notFound">
<element name="notFound"> <element name="notFound">
<ref name="recursionError"/> <ref name="basicError"/>
</element>
</define>
<define name="loop">
<element name="loop">
<ref name="basicError" />
</element> </element>
<ref name="timeToLive"/>
</define> </define>
<define name="serviceNotImplemented"> <define name="serviceNotImplemented">
<element name="serviceNotImplemented"> <element name="serviceNotImplemented">
<ref name="recursionError"/> <ref name="basicError"/>
</element> </element>
<ref name="timeToLive"/>
</define> </define>
<define name="serverTimeout"> <define name="serverTimeout">
<element name="serverTimeout"> <element name="serverTimeout">
<ref name="recursionError"/> <ref name="basicError"/>
</element> </element>
<ref name="timeToLive"/>
</define> </define>
<define name="serverError"> <define name="serverError">
<element name="serverError"> <element name="serverError">
<ref name="recursionError"/> <ref name="basicError"/>
</element> </element>
<ref name="timeToLive"/>
</define> </define>
<define name="locationProfileError"> <define name="locationProfileUnrecognized">
<element name="locationProfileError"> <element name="locationProfileUnrecognized">
<attribute name="unsupportedProfiles"> <attribute name="unsupportedProfiles">
<list> <data type="NMTOKENS" />
<zeroOrMore>
<data type="anyURI"/>
</zeroOrMore>
</list>
</attribute> </attribute>
<ref name="recursionError"/> <ref name="basicError"/>
</element> </element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Redirects. Redirect.
</a:documentation> </a:documentation>
<define name="redirect"> <define name="redirect">
<a:documentation> <a:documentation>
Redirect pattern Redirect pattern
</a:documentation> </a:documentation>
<attribute name="redirect"> <element name="redirect">
<attribute name="target">
<data type="anyURI"/> <data type="anyURI"/>
</attribute> </attribute>
<ref name="error"/> <ref name="source" />
</define> <ref name="message" />
<ref name="extensionPoint" />
<define name="movedPermenantly">
<element name="movedPermanently">
<ref name="redirect"/>
</element>
</define>
<define name="movedTemporarily">
<element name="movedTemporarily">
<ref name="redirect"/>
</element>
<ref name="timeToLive" />
</define>
<define name="iterativeSearchExhausted">
<element name="iterativeSearchExhausted">
<ref name="redirect"/>
</element> </element>
<ref name="timeToLive" />
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Message pattern. Some common patterns.
</a:documentation> </a:documentation>
<define name="message"> <define name="message">
<optional> <optional>
<group> <group>
<attribute name="message"> <attribute name="message">
<data type="string"/> <data type="string"/>
</attribute> </attribute>
<attribute name="xml:lang"> <attribute name="xml:lang">
<data type="language"/> <data type="language"/>
</attribute> </attribute>
</group> </group>
</optional> </optional>
</define> </define>
<define name="service">
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
</define>
<define name="source">
<attribute name="source">
<data type="anyURI" />
</attribute>
</define>
<define name="serviceList" >
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI" />
</zeroOrMore>
</list>
</element>
</define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Patterns for inclusion of elements from schemas in Patterns for inclusion of elements from schemas in
other namespaces. other namespaces.
</a:documentation> </a:documentation>
<define name="notLost"> <define name="notLost">
<a:documentation> <a:documentation>
skipping to change at page 59, line 11 skipping to change at page 67, line 24
</a:documentation> </a:documentation>
<zeroOrMore> <zeroOrMore>
<ref name="notLost" /> <ref name="notLost" />
</zeroOrMore> </zeroOrMore>
</define> </define>
<define name="point2d"> <define name="point2d">
<a:documentation> <a:documentation>
A 2D point from GML. A 2D point from GML.
</a:documentation> </a:documentation>
<element name="position" ns="http://www.opengis.net/gml"> <element name="Point" ns="http://www.opengis.net/gml">
<element name="Point">
<attribute name="srsName"> <attribute name="srsName">
<value>urn:ogc:def:crs:EPSG:4326</value> <value>urn:ogc:def:crs:EPSG::4326</value>
</attribute> </attribute>
<element name="pos"> <ref name="pos"/>
<text/>
</element>
</element> </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> </element>
</define> </define>
<define name="linearRing"> <define name="linearRing">
<a:documentation> <a:documentation>
A Linear Ring from GML. A Linear Ring from GML.
</a:documentation> </a:documentation>
<element name="LinearRing" ns="http://www.opengis.net/gml"> <element name="LinearRing"
<element name="pos"> ns="http://www.opengis.net/gml">
<text/> <ref name="pos"/>
</element> <ref name="pos"/>
<ref name="pos"/>
<oneOrMore>
<ref name="pos"/>
</oneOrMore>
</element> </element>
</define> </define>
<define name="polygon"> <define name="polygon">
<a:documentation> <a:documentation>
A Polygon from GML. A Polygon from GML.
</a:documentation> </a:documentation>
<element name="Polygon" ns="http://www.opengis.net/gml"> <element name="Polygon"
ns="http://www.opengis.net/gml">
<attribute name="srsName"> <attribute name="srsName">
<value>urn:ogc:def:crs:EPSG:4979</value> <value>urn:ogc:def:crs:EPSG::4326</value>
</attribute> </attribute>
<element name="exterior"> <element name="exterior">
<ref name="linearRing"/> <ref name="linearRing"/>
</element> </element>
<zeroOrMore> <zeroOrMore>
<element name="interior"> <element name="interior">
<ref name="linearRing"/> <ref name="linearRing"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
</element> </element>
skipping to change at page 60, line 4 skipping to change at page 68, line 29
<element name="exterior"> <element name="exterior">
<ref name="linearRing"/> <ref name="linearRing"/>
</element> </element>
<zeroOrMore> <zeroOrMore>
<element name="interior"> <element name="interior">
<ref name="linearRing"/> <ref name="linearRing"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
</element> </element>
</define> </define>
</div> </div>
</grammar> </grammar>
Figure 24
Authors' Addresses Authors' Addresses
Ted Hardie Ted Hardie
Qualcomm, Inc. Qualcomm, Inc.
Email: hardie@qualcomm.com Email: hardie@qualcomm.com
Andrew Newton Andrew Newton
SunRocket SunRocket
8045 Leesburg Pike, Suite 300 8045 Leesburg Pike, Suite 300
skipping to change at page 61, line 33 skipping to change at page 69, line 33
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Phone: +49 89 636 40390 Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 276 change blocks. 
924 lines changed or deleted 1307 lines changed or added

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