ECRIT T. Hardie
Internet-Draft Qualcomm, Inc.
Intended status: Standards Track A. Newton
Expires: August 15, 2007 SunRocket
H. Schulzrinne
Columbia U.
H. Tschofenig
Siemens Networks GmbH & Co KG
February 11, 2007
LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Hardie, et al. Expires August 15, 2007 [Page 1]
Internet-Draft LoST February 2007
Abstract
This document describes an XML-based protocol for mapping service
identifiers and geodetic or civic location information to service
contact URIs. In particular, it can be used to determine the
location-appropriate PSAP for emergency services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Requirements Notation . . . . . . . . . . . . 6
3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7
4. LoST servers and Their Resolution . . . . . . . . . . . . . . 8
5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 9
5.1. Data source and version: The 'source', 'sourceId' and
'version' Attributes . . . . . . . . . . . . . . . . . . . 9
5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9
5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9
5.4. Describing the Service with the <displayName> Element . . 10
5.5. The Mapped Service: the <service> Element . . . . . . . . 10
5.6. Defining the Service Region with the <serviceBoundary>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Service Boundaries by Reference: the
<serviceBoundaryReference> Element . . . . . . . . . . . . 11
5.8. The Service Number Element . . . . . . . . . . . . . . . . 11
5.9. Service URLs: the <uri> Element . . . . . . . . . . . . . 12
6. Path of Request: <path> Element . . . . . . . . . . . . . . . 13
7. Mapping a Location and Service to URLs: <findService> . . . . 14
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 14
7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 15
7.3. Components of the <findService> Request . . . . . . . . . 17
7.3.1. The <location> Element . . . . . . . . . . . . . . . . 17
7.3.2. Identifying the Service: The <service> Element . . . 18
7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 18
7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 18
7.3.5. Requesting Civic Location Validation . . . . . . . . . 18
7.4. Components of the Mapping Response
<findServiceResponse> . . . . . . . . . . . . . . . . . . 20
7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 20
7.4.2. Civic Address Validation: the
<locationValidation> Element . . . . . . . . . . . . . 21
8. Retrieving the Service Boundary via <getServiceBoundary> . . . 22
9. List Services: <listServices> . . . . . . . . . . . . . . . . 25
10. List Services By Location: <listServicesByLocation> . . . . . 26
11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 28
Hardie, et al. Expires August 15, 2007 [Page 2]
Internet-Draft LoST February 2007
11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 29
11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 32
11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 33
12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 34
12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 36
13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 37
14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 38
15. Internationalization Considerations . . . . . . . . . . . . . 45
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 46
16.2. Content-type registration for 'application/lost+xml' . . . 46
16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 48
16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 48
16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 49
17. Security Considerations . . . . . . . . . . . . . . . . . . . 50
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 53
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
20.1. Normative References . . . . . . . . . . . . . . . . . . . 54
20.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . . . . 71
Hardie, et al. Expires August 15, 2007 [Page 3]
Internet-Draft LoST February 2007
1. Introduction
This document describes a protocol for mapping a service identifier
[10] and location information compatible with PIDF-LO [7], namely
revised civic location information [11] and GML [13]) to one or more
service URL. Example service URL schemes include sip [14], xmpp
[15], and tel [16]. While the initial focus is on providing mapping
functions for emergency services, it is likely that the protocol is
applicable to any service URN. For example, in the United States,
the "2-1-1" and "3-1-1" service numbers follow a similar location-to-
service behavior as emergency services.
This document names this protocol "LoST", for Location-to-Service
Translation. LoST Satisfies the requirements [18] for mapping
protocols. LoST provides a number of operations, centered around
mapping locations and service URNs to service URLs and associated
information. LoST mapping queries can contain either civic or
geodetic location information. For civic addresses, LoST can
indicate which parts of the civic address are known to be valid or
invalid, thus providing address validation (see Section 3.5 of [18]
for a description of validation). LoST indicates errors in the
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
round trips and to provide robustness against network failures, LoST
caches individual mappings and indicates the region for which the
same answer would be returned ("service region").
As defined in this document, LoST messages are carried in HTTP and
HTTPS protocol exchanges, facilitating use of TLS for protecting the
integrity and confidentiality of requests and responses. Later
documents may describe how LoST messages could be carried over other
transports.
This document focuses on the description of the protocol between the
mapping client and the mapping server. The relationship between
other functions, such as discovery of mapping servers, data
replication and the overall mapping server architecture are described
in a separate document [19].
The query message carries location information and a service
identifier encoded as a Uniform Resource Name (URN) (see [10]) from
the LoST client to the LoST server. The LoST server uses its
database to map the input values to one or more Uniform Resource
Identifiers (URI) and returns those URIs along with optional
information, such as hints about the service boundary, in a response
message to the LoST client. If the server cannot resolve the query
Hardie, et al. Expires August 15, 2007 [Page 4]
Internet-Draft LoST February 2007
itself, it may in turn query another server or return the address of
another LoST server, identified by a LoST server name. In addition
to the mapping function described in Section 7, the protocol also
allows to retrieve the service boundary (see Section 8) and to list
the services available for a particular location (see Section 10) or
supported by a particular server (see Section 9).
Hardie, et al. Expires August 15, 2007 [Page 5]
Internet-Draft LoST February 2007
2. Terminology and Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
This document furthermore uses the terminology defined in [18].
Hardie, et al. Expires August 15, 2007 [Page 6]
Internet-Draft LoST February 2007
3. Overview of Protocol Usage
The client may perform the mapping at any time. Among the common
triggers for mapping requests are:
1. When the client initially starts up or attaches to a network.
2. When the client detects that its location has changed
sufficiently that it is outside the bounds of the service region
returned in an earlier LoST query.
3. When cached mapping information has expired.
4. When invoking a particular service. At that time, a client may
omit requests for service boundaries or other auxiliary
information.
A service-specific Best Current Practice (BCP) document, such as
[20], governs whether a client is expected to invoke the mapping
service just before needing the service or whether to rely on cached
answers. Cache entries expire at their expiration time (see
Section 5.3), or they become invalid if the caller's device moves
beyond the boundaries of the service region.
Hardie, et al. Expires August 15, 2007 [Page 7]
Internet-Draft LoST February 2007
4. LoST servers and Their Resolution
A LoST server may be discovered using a U-NAPTR/DDDS [12] application
unique string (AUS), in the form of a DNS name.
An example is 'lostserver.example.com'
Clients need to use the U-NAPTR [12] specification described below to
obtain a URI (indicating host and protocol) for the applicable LoST
service. In this document, only the HTTP and HTTPS URL schemes are
defined. Note that the HTTP URL can be any valid HTTP URL, including
those containing path elements.
The following two DNS entries show the U-NAPTR resolution for the AUS
"example.com" to the HTTPS URL https://lostserv.example.com/secure or
the HTTP URL http://lostserver.example.com, with the former being
preferred.
example.com.
IN NAPTR 100 10 "u" "LoST:https"
"!*.!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http"
"!*.!http://lostserver.example.com!" ""
Clients learn the LoST server's AUS by means beyond the scope of this
specification, such as SIP configuration and DHCP.
Hardie, et al. Expires August 15, 2007 [Page 8]
Internet-Draft LoST February 2007
5. The <mapping> Element
The <mapping> element is the core data element in LoST, describing a
service region and the associated service URLs. Its attributes and
elements are described in subsections below.
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. All three attributes are REQUIRED for all <mapping>
elements. A receiver can replace a mapping with another one having
the same 'source' and 'sourceId' and a higher version number.
The 'source' attribute contains a LoST application unique string
identifying the authoritative generator of the mapping. See
Section 4.
The 'sourceId' attribute identifies a particular mapping and contains
an opaque token that MUST be unique among all different mappings
maintained by the authoritative source for that particular service.
For example, a Universally Unique Identifier (UUID) is a suitable
format.
The 'version' attribute is a positive integer that is incremented for
each change in the mapping. The XML data type does not specify an
upper bound for this attribute and thus, the value MUST NOT wrap
around. 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.
5.2. Time of Last Update: The 'lastUpdated' Attribute
The 'lastUpdated' attribute describes when the mapping was last
changed. The contents of this attribute has the XML data type
dateTime in its timezoned form, using canonical UTC representation
with the letter 'Z' as the timezone indicator. The attribute is
REQUIRED.
5.3. Validity: The 'expires' Attribute
The 'expires' attribute contains the absolute time at which the
mapping becomes invalid. 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.
Hardie, et al. Expires August 15, 2007 [Page 9]
Internet-Draft LoST February 2007
The 'expires' attribute is REQUIRED to be included in the <mapping>
element.
On occasion, a server may be forced to return an expired mapping if
it cannot reach the authoritative server or the server fails to
return a usable answer. Clients and servers MAY cache the mapping so
that they have at least some information available. Caching servers
that have such stale information SHOULD re-attempt the query each
time a client requests a mapping.
5.4. Describing the Service with the <displayName> Element
Zero or more <displayName> elements describe the service with a
string that is suitable for display to human users, each 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. Two cases need to be distinguished when the LoST server
sets the <service> element in the response message:
1. If the requested service, identified by the service URN [10] in
the <service> element of the request, exists for the location
indicated, then the LoST server puts the service URN from the
request into the <service> element.
2. If, however, 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 is optional but may also be required if the
mapping is to be digitally signed.
5.6. Defining the Service Region with the <serviceBoundary> Element
A response MAY indicate the region for which the service URL returned
would be the same as in the actual query, the so-called _service
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 sends a new query
Hardie, et al. Expires August 15, 2007 [Page 10]
Internet-Draft LoST February 2007
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
(see Section 11). The response MUST contain at least one service
boundary using the same profile as the request. The client only
processes the first element that it can understand according to its
list of supported location profiles. Thus, elements with geospatial
coordinates are alternative descriptions of the same service region,
not additive geometries.
A response MAY contain more than one <serviceBoundary> element with
profile 'civic'. Each <serviceBoundary> element describes a set of
civic addresses that fall within the service boundary, namely all
addresses that textually match the civic address elements provided,
regardless of the value of other address elements. A location falls
within the mapping's service boundary if it matches any of the
<serviceBoundary> elements.
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 application unique string (see Section 4)
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 unnecessarily refreshing the boundary information just because
the the remainder of the mapping has become invalid.
5.8. The Service Number Element
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
Hardie, et al. Expires August 15, 2007 [Page 11]
Internet-Draft LoST February 2007
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'.
Hardie, et al. Expires August 15, 2007 [Page 12]
Internet-Draft LoST February 2007
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 application unique string (see Section 4). 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 client. 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.
Hardie, et al. Expires August 15, 2007 [Page 13]
Internet-Draft LoST February 2007
7. Mapping a Location and Service to URLs: <findService>
7.1. Overview
The <findService> query constitutes the core of the LoST
functionality, mapping civic or geodetic locations to URLs and
associated data. After giving an example, we enumerate the elements
of the query and response.
7.2. Examples
7.2.1. Example Using Geodetic Coordinates
The following is an example of mapping a service to a location using
geodetic coordinates, for the service associated with the police
(urn:service:sos.police).
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
serviceBoundary="value"
recursive="true">
<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>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 2: A <findService> geodetic query
Given the query above, a server would respond with a service, and
information related to that service. In the example below, the
server has mapped the location given by the client for a police
service to the New York City Police Deparment, instructing the client
that it may contact them via the URIs "sip:sfpd@example.com" and
"xmpp:sfpd@example.com". The server has also given the client a
geodetic, two-dimensional boundary for this service. The mapping was
last updated on November 1, 2006 and expires on January 1, 2007. If
the client's location changes beyond the given service boundary or
the expiration time has been reached, it may want to requery for this
information, depending on the usage environment of LoST.
Hardie, et al. Expires August 15, 2007 [Page 14]
Internet-Draft LoST February 2007
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">
<displayName xml:lang="en">
San Francisco 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:sfpd@example.com</uri>
<uri>xmpp:sfpd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="authoritative.example"/>
<via source="resolver.example"/>
</path>
</findServiceResponse>
Figure 3: A <findServiceResponse> geodetic answer
7.2.2. Civic Address Mapping Example
The following is an example of mapping a service to a location much
like the example in Section 7.2.1, but using civic address location
information. In this example, the client requests the service
associated with police (urn:service:sos.police) along with a specific
civic address (house number 6 on a street named Otto-Hahn-Ring in
Munich, Germany).
Hardie, et al. Expires August 15, 2007 [Page 15]
Internet-Draft LoST February 2007
<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true" serviceBoundary="value">
<location
profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</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 4: A <findService> civic address query
Given the query above, a server would respond with a service, and
information related to that service. In the example below, the
server has mapped the location given by the client for a police
service to the Muenchen Polizei-Abteilung, instructing the client
that it may contact them via the URIs sip:munich-police@example.com
and xmpp:munich-police@example.com. The server has also given the
client a civic address boundary (the city of Munich) for this
service. The mapping was last updated on November 1, 2006 by the
authoritative source "polizei.muenchen.de.example" and expires on
January 1, 2007. This instructs the client to requery for the
information if its location changes beyond the given service boundary
(i.e., beyond the city of Munich) or after January 1, 2007.
Hardie, et al. Expires August 15, 2007 [Page 16]
Internet-Draft LoST February 2007
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="esgw.ueber-110.de.example"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109" version="1" >
<displayName xml:lang="de">
Muenchen Polizei-Abteilung
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</mapping>
<path>
<via source="esgw.ueber-110.de.example"/>
<via source="polizei.muenchen.de.example"/>
</path>
</findServiceResponse>
Figure 5: A <findServiceResponse> civic address answer
7.3. Components of the <findService> Request
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 information using one
or more <location> elements, which MUST conform to a location profile
(see Section 11). There MUST NOT be 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.
Hardie, et al. Expires August 15, 2007 [Page 17]
Internet-Draft LoST February 2007
7.3.2. Identifying the Service: The <service> Element
The type of service desired is specified by the <service> element.
It contains service URNs from the registry established in [10].
7.3.3. Recursion
LoST <findService> and <listServicesByLocation> queries can be
recursive, as indicated by the 'recursive' attribute. A value of
"true" indicates a recursive query, with the default being "false"
when the attribute is omitted. Regardless of the attribute, a server
MAY always answer a query by providing a LoST application unique
string (see Section 4), i.e., indirection, however, it MUST NOT
recurse if the attribute is "false".
In recursive mode, the LoST server initiates queries on behalf of the
requester and returns the result to the requester, inserting a <via>
element to track the response chain. The <via> elements are appended
in responses in order of visit, i.e., the first <via> element
contains the authoritative server and <via> elements below indicate
servers that the response traversed on its way back to the original
querier.
7.3.4. Service Boundary
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.
7.3.5. Requesting Civic Location Validation
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.
Hardie, et al. Expires August 15, 2007 [Page 18]
Internet-Draft LoST February 2007
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true"
validateLocation="true"
serviceBoundary="value">
<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
Hardie, et al. Expires August 15, 2007 [Page 19]
Internet-Draft LoST February 2007
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="4db898df52b84edfa9b6445ea8a0328e"
version="1" >
<displayName xml:lang="de">
Muenchen Polizei-Abteilung
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</mapping>
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
</locationValidation>
<path>
<via source="authoritative.example"/>
<via source="resolver.example"/>
</path>
</findServiceResponse>
Figure 7: A <findServiceResponse> message with address validation
information
7.4. Components of the Mapping Response <findServiceResponse>
7.4.1. Overview
Mapping responses consist of the <mapping> element (Section 5)
describing the mapping itself, possibly followed by warnings
(Section 12.2), location validation information (Section 7.4.2), and
an indication of the path (Section 6) the response has taken.
Hardie, et al. Expires August 15, 2007 [Page 20]
Internet-Draft LoST February 2007
7.4.2. Civic Address Validation: the <locationValidation> Element
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 checked and found to be invalid. The server MUST include this
information if the 'validateLocation' attribute in the request was
true. Each element contains a list of tokens separated by white
space, enumerating the civic location lables used in child elements
of the <civicAddress> element. The <valid> element enumerates those
civic address elements that have been recognized as valid by the LoST
server and that have been used to determine the mapping. The
<unchecked> elements enumerates the civic address elements that the
server did not check and that were not used in determining the
response. The <invalid> element enumerate civic address elements
that the server attempted to check, but that did not match the other
civic address elements found in the <valid> list.
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',
'A3', and 'A6' have been validated by the LoST server. The server
considered the postal code 81675 in the <PC> element as not valid for
this location.
Hardie, et al. Expires August 15, 2007 [Page 21]
Internet-Draft LoST February 2007
8. Retrieving the Service Boundary via <getServiceBoundary>
As discussed in Section 5.6, the <findServiceResponse> can return a
globally unique identifier in the 'serviceBoundary' attribute that
can be used to retrieve the service boundary, rather than returning
the boundary by value. This is shown in the example in Figure 8.
The client can then retrieve the boundary using the
<getServiceBoundary> request and obtains the boundary in the
<getServiceBoundaryResponse>, illustrated in the example in
Figure 10. The client issues the request to the server identified in
the 'server' attribute of the <serviceBoundaryReference> element.
These requests are always directed to the authoritative server and do
not recurse.
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
recursive="true"
serviceBoundary="reference">
<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>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 8: <findService> request and response with service boundary
reference
Hardie, et al. Expires August 15, 2007 [Page 22]
Internet-Draft LoST February 2007
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
version="1">
<displayName xml:lang="en">
San Francisco Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundaryReference
source="authoritative.example"
key="7214148E0433AFE2FA2D48003D31172E" />
<uri>sip:sfpd@example.com</uri>
<uri>xmpp:sfpd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="authoritative.example"/>
<via source="resolver.example"/>
</path>
</findServiceResponse>
Figure 9: <findServiceResponse> message with service boundary
reference
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
key="7214148E0433AFE2FA2D48003D31172E"/>
Figure 10: Requesting a service boundary with <getServiceBoundary>
The <getServiceBoundary> request may also be used to retrieve service
boundaries that are expressed as civic addresses, as illustrated in
Figure 11.
Hardie, et al. Expires August 15, 2007 [Page 23]
Internet-Draft LoST February 2007
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceBoundary
profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
</civicAddress>
</serviceBoundary>
<path>
<via source="authoritative.example"/>
<via source="resolver.example"/>
</path>
</getServiceBoundaryResponse>
Figure 11: Civic Address Service Boundary Response
Hardie, et al. Expires August 15, 2007 [Page 24]
Internet-Draft LoST February 2007
9. List Services: <listServices>
A LoST client can ask a LoST server for the list of services that it
understands, primarily for diagnostic purposes. The query does not
contain location information, as it simply provides an indication of
which services the server can look up, not whether a particular
service is offered for a particular area. Typically, only top-level
services are included in the answer, implying support for all sub-
services. Since the query is answered by the queried server, there
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.
<?xml version="1.0" encoding="UTF-8"?>
<listServices
xmlns="urn:ietf:params:xml:ns:lost1">
<service>urn:service:sos</service>
</listServices>
Figure 12: Example of <ListServices> query
<?xml version="1.0" encoding="UTF-8"?>
<listServicesResponse
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>
</listServicesResponse>
Figure 13: Example of <ListServiceResponse>
Hardie, et al. Expires August 15, 2007 [Page 25]
Internet-Draft LoST February 2007
10. List Services By Location: <listServicesByLocation>
A LoST client can ask a LoST server for the list of services it knows
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.
If the query contains the <service> element, the LoST server returns
only immediate child services of the queried service that are
available for the provided location. If the <service> element is
absent, the LoST service returns all top-level services available for
the provided location that it knows about.
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
Hardie, et al. Expires August 15, 2007 [Page 26]
Internet-Draft LoST February 2007
<?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="authoritative.example"/>
<via source="resolver.example"/>
</path>
</listServicesByLocationResponse>
Figure 15: Example of <ListServices> response
Hardie, et al. Expires August 15, 2007 [Page 27]
Internet-Draft LoST February 2007
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>
elements MUST contain location information in exactly one of the two
baseline profiles, in addition to zero or more additional profiles.
The ordering of location information indicates a preference on the
part of the sender.
Standards action is required for defining new profiles. A location
profile MUST define:
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
enumeration and definition of the XML child elements of the
<location> element;
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
<serviceBoundary> element;
4. The declaration of whether geodetic-2d or civic is to be used as
the baseline profile. It is necessary to explicitly declare the
baseline profile as future profiles may be combinations of
geodetic and civic location information.
Hardie, et al. Expires August 15, 2007 [Page 28]
Internet-Draft LoST February 2007
11.1. Location Profile Usage
A location profile is identified by a token in an IANA-maintained
registry (Section 16.5). Clients send location information compliant
with a location profile, and servers respond with location
information compliant with that same location profile.
When a LoST client sends a <findService> request that provides
location information, it includes one or more <location> elements. A
<location> element carries a mandatory 'profile' attribute that
indicates the location format of the child elements. The concept of
location profiles are described in Section 11. With the ability to
specify more than one <location> element the client is able to convey
location information for multiple location profiles in the same
request.
When a LoST server sends a response that contains location
information, it uses the <serviceBoundary> elements much like the
client uses the <location> elements. Each <serviceBoundary> element
contains location information conformant to the location profile
specified in the 'profile' attribute. When multiple <location>
elements are included then it enables the server to send location
information compliant with multiple location profiles.
Using the location profiles defined in this document, the following
rules insure basic interoperatiblity between clients and servers:
1. A client MUST be capable of understanding the response for the
baseline profiles it used in the request.
2. If a client sends location information conformant to any location
profile other than geodetic-2d or civic, it MUST also send, in
the same request, location information conformant to one of the
baseline profiles. Otherwise, the server might not be able to
understand the request.
3. There can only be one instance of each location profile in a
query.
4. Servers MUST implement the geodetic-2d and civic profiles.
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
responds with a <locationProfileError> (Section 12.1).
Hardie, et al. Expires August 15, 2007 [Page 29]
Internet-Draft LoST February 2007
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,
while ensuring baseline interoperability. Take, for example, this
scenario. Client X has had its firmware upgraded to support the
uber-complex-3D location profile. Client X sends location
information to Server Y, which does not understand the
uber-complex-3D location profile. If Client X also sends location
information using the geodetic-2D baseline profile, then Server Y
will still be able to understand the request and provide an
understandable response, though with location information that might
not be as precise or expressive as desired. This is possible because
both Client X and Server Y understand the baseline profile.
Hardie, et al. Expires August 15, 2007 [Page 30]
Internet-Draft LoST February 2007
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
recursive="true"
serviceBoundary="value">
<location profile="uber-complex-3d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
<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>
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>-122.422 37.775</p2:pos>
</p2:Point>
</location>
<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>
</location>
<service>urn:service:sos.police</service>
</findService>
Figure 16: Example of a <findServices> query with baseline profile
interoperability
Hardie, et al. Expires August 15, 2007 [Page 31]
Internet-Draft LoST February 2007
<?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="authoritative.example"
sourceId="cf19bbb038fb4ade95852795f045387d"
version="1">
<displayName xml:lang="en">
San Francisco 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="authoritative.example"/>
<via source="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.
Clients use this profile by placing a GML [13] <position> element
within the <location> element. This is defined by the 'point2D'
pattern in the LoST schema (see Section 14).
Servers use this profile by placing a GML [13] <Polygon> element
within the <serviceBoundary> element. This is defined by the
'polygon' pattern in the LoST schema (see Section 14).
Hardie, et al. Expires August 15, 2007 [Page 32]
Internet-Draft LoST February 2007
11.3. Basic Civic Profile
The basic-civic location profile is identified by the token 'civic'.
Clients use this profile by placing a <civicAddress> element, defined
in [11], within the <location> element.
Servers use this profile by placing a <civicAddress> element, defined
in [11], within the <serviceBoundary> element.
Hardie, et al. Expires August 15, 2007 [Page 33]
Internet-Draft LoST February 2007
12. Errors, Warnings, and Redirects
When a LoST server cannot fulfill a request completely, it can return
either an error or a warning, depending on the severity of the
problem. It returns an error element if no useful response can be
returned for the query. It returns a <warnings> element as part of
another response element if it was able to respond in part, but the
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.
12.1. Errors
LoST defines a pattern for errors, defined as <errors> elements in
the Relax NG schema. 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 error
elements are contained in the <errors> element.
The following errors follow this basic pattern:
badRequest
The server could not parse or otherwise understand a request,
e.g., because the XML was malformed.
forbidden
The server refused to send an answer. This generally only occurs
for recursive queries, namely if the client tried to contact the
authoritative server and was refused. (For HTTP as the underlying
protocol, an HTTP 401 error would be returned.)
internalError
The server could not satisfy a request due to misconfiguration or
other operational and non-protocol related reasons.
locationProfileUnrecognized
None of the profiles in the request were recognized by the server
(see Section 11).
Hardie, et al. Expires August 15, 2007 [Page 34]
Internet-Draft LoST February 2007
loop
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.
notFound
The server could not find an answer to the query.
serverError
An answer was received from another LoST server, but it could not
be parsed or otherwise understood. This error occurs only for
recursive queries.
serverTimeout
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="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.
Hardie, et al. Expires August 15, 2007 [Page 35]
Internet-Draft LoST February 2007
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 application
unique string (see Section 4) 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="eastpsap.example"
source="westpsap.example"
message="We have temporarily failed over." xml:lang="en"/>
Figure 19: Example of a redirect resonse
Hardie, et al. Expires August 15, 2007 [Page 36]
Internet-Draft LoST February 2007
13. LoST Transport
LoST needs an underlying protocol transport mechanisms to carry
requests and responses. This document defines the use of LoST over
HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future
documents. The available transport mechanisms are determined through
the use of the LoST U-NAPTR application. In protocols that support
content type indication, LoST uses the media type application/
lost+xml.
When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP
POST method. All HTTP responses are applicable. The HTTP URL is
derived from the LoST server name via U-NAPTR application, as
discussed above
Hardie, et al. Expires August 15, 2007 [Page 37]
Internet-Draft LoST February 2007
14. Relax NG Schema
This section provides the Relax NG schema used by LoST protocol in
the compact form. The verbose form is included in Appendix A.
default namespace = "http://www.opengis.net/gml"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace ns1 = "urn:ietf:params:xml:ns:lost1"
##
## Location-to-Service Translation Protocol (LoST)
##
## A LoST XML instance has three request types, each with
## a cooresponding response type: find service, list services,
## and get service boundary.
##
start =
findService
| listServices
| listServicesByLocation
| getServiceBoundary
| findServiceResponse
| listServicesResponse
| listServicesByLocationResponse
| getServiceBoundaryResponse
| errors
| redirect
##
## The queries.
##
div {
findService =
element ns1:findService {
element ns1:location { locationInformation }+,
commonRequestPattern,
attribute validateLocation {
xsd:boolean >> a:defaultValue [ "false" ]
}?,
attribute serviceBoundary {
("reference" | "value") >> a:defaultValue [ "reference" ]
}?,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
}
listServices = element ns1:listServices { commonRequestPattern }
Hardie, et al. Expires August 15, 2007 [Page 38]
Internet-Draft LoST February 2007
listServicesByLocation =
element ns1:listServicesByLocation {
element ns1:location { locationInformation }*,
commonRequestPattern,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
}
getServiceBoundary =
element ns1:getServiceBoundary {
serviceBoundaryKey, extensionPoint
}
}
##
## The responses.
##
div {
findServiceResponse =
element ns1:findServiceResponse {
mapping+, locationValidation?, commonResponsePattern
}
listServicesResponse =
element ns1:listServicesResponse {
serviceList, commonResponsePattern
}
listServicesByLocationResponse =
element ns1:listServicesByLocationResponse {
serviceList, commonResponsePattern
}
getServiceBoundaryResponse =
element ns1:getServiceBoundaryResponse {
serviceBoundary, commonResponsePattern
}
}
##
## A pattern common to some of the queries.
##
div {
commonRequestPattern = service, extensionPoint
}
##
## A pattern common to responses.
##
div {
commonResponsePattern = warnings*, path, extensionPoint
}
Hardie, et al. Expires August 15, 2007 [Page 39]
Internet-Draft LoST February 2007
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }
}
##
## Service Boundary
##
div {
serviceBoundary = element ns1:serviceBoundary { locationInformation }+
}
##
## Service Boundary Reference
##
div {
serviceBoundaryReference =
element ns1:serviceBoundaryReference {
source, serviceBoundaryKey, extensionPoint
}
serviceBoundaryKey = attribute key { xsd:token }
}
##
## Path -
## Contains a list of via elements -
## places through which information flowed
##
div {
path =
element ns1:path {
element ns1:via { source, extensionPoint }*
}
}
##
## Expires pattern
##
div {
expires = attribute expires { xsd:dateTime }
}
##
## A QName list
Hardie, et al. Expires August 15, 2007 [Page 40]
Internet-Draft LoST February 2007
##
div {
qnameList = list { xsd:QName* }
}
##
## A location-to-service mapping.
##
div {
mapping =
element ns1:mapping {
element ns1:displayName {
xsd:string,
attribute xml:lang { xsd:language }
}*,
service,
(serviceBoundary | serviceBoundaryReference)?,
element ns1:uri { xsd:anyURI }*,
element ns1:serviceNumber {
xsd:string { pattern = "[0-9*#]+" }
}?,
extensionPoint,
expires,
attribute lastUpdated { xsd:dateTime },
source,
attribute sourceId { xsd:token },
attribute version { xsd:positiveInteger },
message
}
}
##
## Location validation
##
div {
locationValidation =
element ns1:locationValidation {
element ns1:valid { qnameList }?,
element ns1:invalid { qnameList }?,
element ns1:unchecked { qnameList }?,
extensionPoint
}
}
##
## Errors and Warnings Container.
##
div {
Hardie, et al. Expires August 15, 2007 [Page 41]
Internet-Draft LoST February 2007
errorContainer =
(badRequest?
& internalError?
& serviceSubstitution?
& forbidden?
& notFound?
& loop?
& serviceNotImplemented?
& serverTimeout?
& serverError?
& locationProfileUnrecognized?),
extensionPoint,
source
errors = element ns1:errors { errorContainer }
warnings = element ns1:warnings { errorContainer }
}
##
## Basic Errors
##
div {
##
## Error pattern.
##
basicError = message, extensionPoint
badRequest = element ns1:badRequest { basicError }
internalError = element ns1:internalError { basicError }
serviceSubstitution = element ns1:serviceSubstitution { basicError }
forbidden = element ns1:forbidden { basicError }
notFound = element ns1:notFound { basicError }
loop = element ns1:loop { basicError }
serviceNotImplemented =
element ns1:serviceNotImplemented { basicError }
serverTimeout = element ns1:serverTimeout { basicError }
serverError = element ns1:serverError { basicError }
locationProfileUnrecognized =
element ns1:locationProfileUnrecognized {
attribute unsupportedProfiles { xsd:NMTOKENS },
basicError
}
}
##
## Redirect.
##
div {
Hardie, et al. Expires August 15, 2007 [Page 42]
Internet-Draft LoST February 2007
##
## Redirect pattern
##
redirect =
element ns1:redirect {
attribute target { appUniqueString },
source,
message,
extensionPoint
}
}
##
## Some common patterns.
##
div {
message =
(attribute message { xsd:string },
attribute xml:lang { xsd:language })?
service = element ns1:service { xsd:anyURI }?
appUniqueString =
xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
source = attribute source { appUniqueString }
serviceList =
element ns1:serviceList {
list { xsd:anyURI* }
}
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Any element not in the LoST namespace.
##
notLost = element * - (ns1:* | ns1:*) { anyElement }
##
## A wildcard pattern for including any element
## from any other namespace.
##
anyElement =
(element * { anyElement }
| attribute * { text }
| text)*
Hardie, et al. Expires August 15, 2007 [Page 43]
Internet-Draft LoST February 2007
##
## A point where future extensions
## (elements from other namespaces)
## can be added.
##
extensionPoint = notLost*
##
## A 2D point from GML.
##
point2d =
element Point {
attribute srsName { "urn:ogc:def:crs:EPSG::4326" },
pos
}
##
## A GML position
##
pos =
element pos {
list { xsd:double }
}
##
## A Linear Ring from GML.
##
linearRing = element LinearRing { pos, pos, pos, pos+ }
##
## A Polygon from GML.
##
polygon =
element Polygon {
attribute srsName { "urn:ogc:def:crs:EPSG::4326" },
element exterior { linearRing },
element interior { linearRing }*
}
}
Figure 20: RelaxNG schema
Hardie, et al. Expires August 15, 2007 [Page 44]
Internet-Draft LoST February 2007
15. Internationalization Considerations
This mechanism is largely for passing protocol information from one
subsystem to another; as such, most of its elements are tokens not
meant for direct human consumption. If these tokens are presented to
the end user, some localization may need to occur. The content of
the <displayName> element and the 'message' attributes may be
displayed to the end user, and they are thus a complex types designed
for this purpose.
LoST exchanges information using XML. All XML processors are
required to understand UTF-8 and UTF-16 encodings, and therefore all
LoST clients and servers MUST understand UTF-8 and UTF-16 encoded
XML. Additionally, LoST servers and clients MUST NOT encode XML with
encodings other than UTF-8 or UTF-16.
Hardie, et al. Expires August 15, 2007 [Page 45]
Internet-Draft LoST February 2007
16. IANA Considerations
16.1. U-NAPTR Registrations
This document registers the following U-NAPTR application service
tag:
Application Service Tag: LoST
Defining Publication: The specification contained within this
document.
This document registers the following U-NAPTR application protocol
tags:
o
Application Protocol Tag: http
Defining Publication: RFC 2616 [3]
o
Application Protocol Tag: https
Defining Publication: RFC 2818 [4]
16.2. Content-type registration for 'application/lost+xml'
This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [8] and guidelines in RFC
3023 [5].
MIME media type name: application
MIME subtype name: lost+xml
Mandatory parameters: none
Optional parameters: charset
Indicates the character encoding of enclosed XML.
Hardie, et al. Expires August 15, 2007 [Page 46]
Internet-Draft LoST February 2007
Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See RFC 3023 [5], Section 3.2.
Security considerations:
This content type is designed to carry LoST protocol payloads.
Interoperability considerations: None
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number of this specification.] this
document
Applications which use this media type:
Emergency and Location-based Systems
Additional information:
Magic Number: None
File Extension: .lostxml
Macintosh file type code: 'TEXT'
Personal and email address for further information: Hannes
Tschofenig, Hannes.Tschofenig@siemens.com
Intended usage: LIMITED USE
Author:
This specification is a work item of the IETF ECRIT working group,
with mailing list address <ecrit@ietf.org>.
Hardie, et al. Expires August 15, 2007 [Page 47]
Internet-Draft LoST February 2007
Change controller:
The IESG <iesg@ietf.org> delegated to the IETF ECRIT working
group, if it is still active.
16.3. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
Relax NG Schema: The Relax NG schema to be registered is contained
in Section 14. Its first line is
default namespace = "urn:ietf:params:xml:ns:lost1"
and its last line is
}
16.4. LoST Namespace Registration
URI: urn:ietf:params:xml:ns:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
XML:
Hardie, et al. Expires August 15, 2007 [Page 48]
Internet-Draft LoST February 2007
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Namespace</title>
</head>
<body>
<h1>Namespace for LoST</h1>
<h2>urn:ietf:params:xml:ns:lost1</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
16.5. LoST Location Profile Registry
This document seeks to create a registry of location profile names
for the LoST protocol. Profile names are XML tokens. This registry
will operate in accordance with RFC 2434 [2], Standards Action.
geodetic-2d:
Defined in Section 11.2
civic:
Defined in Section 11.3
Hardie, et al. Expires August 15, 2007 [Page 49]
Internet-Draft LoST February 2007
17. Security Considerations
There are multiple threats to the overall system of which service
mapping forms a part. An attacker that can obtain service contact
URIs can use those URIs to attempt to disrupt those services. An
attacker that can prevent the lookup of contact URIs can impair the
reachability of such services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an
emergency and possibly its nature, and may be able to use this to
launch a physical attack on the caller.
To avoid that an attacker can modify the query or its result, the use
of channel security, such as TLS, is RECOMMENDED.
Generally, authentication and authorization is not required for
mapping queries. If it is, authentication mechanism of the
underlying transport mechanism, such as HTTP basic and digest
authentication, MAY be used. (Basic authentication SHOULD only be
used in combination with TLS.)
A more detailed description of threats and security requirements are
provided in [17].
Hardie, et al. Expires August 15, 2007 [Page 50]
Internet-Draft LoST February 2007
18. Acknowledgments
We would like to the thank the following working group members for
the detailed review of previous LoST document versions:
o Martin Thomson (Review July 2006)
o Jonathan Rosenberg (Review July 2006)
o Leslie Daigle (Review September 2006)
o Shida Schubert (Review November 2006)
o Martin Thomson (Review December 2006)
o Barbara Stark (Review January 2007)
o Patrik Faeltstroem (Review January 2007
o Shida Schubert (Review January 2007 as a designated expert
reviewer)
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 (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)
Hardie, et al. Expires August 15, 2007 [Page 51]
Internet-Draft LoST February 2007
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)
Klaus Darilion and Marc Linsner provided miscellaneous input to the
design of the protocol. Finally, we would like to thank Brian Rosen
who participated in almost every discussion thread.
Hardie, et al. Expires August 15, 2007 [Page 52]
Internet-Draft LoST February 2007
19. Open Issues
Please find open issues at: http://www.ietf-ecrit.org:8080/lost/
Hardie, et al. Expires August 15, 2007 [Page 53]
Internet-Draft LoST February 2007
20. References
20.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[7] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[8] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[9] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-ietf-ecrit-service-urn-05 (work in progress),
August 2006.
[11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in
progress), September 2006.
[12] Daigle, L., "Domain-based Application Service Location Using
URIs and the Dynamic Delegation Discovery Service (DDDS)",
draft-daigle-unaptr-01 (work in progress), October 2006.
[13] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC OGC 02-023r4, January 2003.
Hardie, et al. Expires August 15, 2007 [Page 54]
Internet-Draft LoST February 2007
20.2. Informative References
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
October 2004.
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[17] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-ietf-ecrit-security-threats-03
(work in progress), July 2006.
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-12 (work in progress),
August 2006.
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-01 (work in
progress), December 2006.
[20] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006.
Hardie, et al. Expires August 15, 2007 [Page 55]
Internet-Draft LoST February 2007
Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost1"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<a:documentation>
Location-to-Service Translation Protocol (LoST)
A LoST XML instance has three request types, each with
a cooresponding response type: find service, list services,
and get service boundary.
</a:documentation>
<choice>
<ref name="findService" />
<ref name="listServices" />
<ref name="listServicesByLocation" />
<ref name="getServiceBoundary" />
<ref name="findServiceResponse" />
<ref name="listServicesResponse" />
<ref name="listServicesByLocationResponse" />
<ref name="getServiceBoundaryResponse" />
<ref name="errors" />
<ref name="redirect" />
</choice>
</start>
<div>
<a:documentation>
The queries.
</a:documentation>
<define name="findService">
<element name="findService">
<oneOrMore>
<element name="location">
<ref name="locationInformation" />
</element>
</oneOrMore>
<ref name="commonRequestPattern" />
<optional>
<attribute name="validateLocation">
<data type="boolean" />
<a:defaultValue>false</a:defaultValue>
Hardie, et al. Expires August 15, 2007 [Page 56]
Internet-Draft LoST February 2007
</attribute>
</optional>
<optional>
<attribute name="serviceBoundary">
<choice>
<value>reference</value>
<value>value</value>
</choice>
<a:defaultValue>reference</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="recursive">
<data type="boolean" />
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="listServices">
<element name="listServices">
<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>
</define>
<define name="getServiceBoundary">
<element name="getServiceBoundary">
<ref name="serviceBoundaryKey" />
<ref name="extensionPoint" />
</element>
Hardie, et al. Expires August 15, 2007 [Page 57]
Internet-Draft LoST February 2007
</define>
</div>
<div>
<a:documentation>
The responses.
</a:documentation>
<define name="findServiceResponse">
<element name="findServiceResponse">
<oneOrMore>
<ref name="mapping" />
</oneOrMore>
<optional>
<ref name="locationValidation" />
</optional>
<ref name="commonResponsePattern" />
</element>
</define>
<define name="listServicesResponse">
<element name="listServicesResponse">
<ref name="serviceList" />
<ref name="commonResponsePattern" />
</element>
</define>
<define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse">
<ref name="serviceList" />
<ref name="commonResponsePattern" />
</element>
</define>
<define name="getServiceBoundaryResponse">
<element name="getServiceBoundaryResponse">
<ref name="serviceBoundary"/>
<ref name="commonResponsePattern" />
</element>
</define>
</div>
<div>
Hardie, et al. Expires August 15, 2007 [Page 58]
Internet-Draft LoST February 2007
<a:documentation>
A pattern common to some of the queries.
</a:documentation>
<define name="commonRequestPattern">
<ref name="service" />
<ref name="extensionPoint" />
</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>
<a:documentation>
Location Information
</a:documentation>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<attribute name="profile">
<data type="NMTOKEN" />
</attribute>
</define>
</div>
<div>
<a:documentation>
Service Boundary
</a:documentation>
<define name="serviceBoundary">
<oneOrMore>
<element name="serviceBoundary">
<ref name="locationInformation" />
Hardie, et al. Expires August 15, 2007 [Page 59]
Internet-Draft LoST February 2007
</element>
</oneOrMore>
</define>
</div>
<div>
<a:documentation>
Service Boundary Reference
</a:documentation>
<define name="serviceBoundaryReference">
<element name="serviceBoundaryReference">
<ref name="source" />
<ref name="serviceBoundaryKey" />
<ref name="extensionPoint" />
</element>
</define>
<define name="serviceBoundaryKey">
<attribute name="key">
<data type="token" />
</attribute>
</define>
</div>
<div>
<a:documentation>
Path -
Contains a list of via elements -
places through which information flowed
</a:documentation>
<define name="path">
<element name="path">
<zeroOrMore>
<element name="via">
<ref name="source" />
<ref name="extensionPoint" />
</element>
</zeroOrMore>
</element>
</define>
</div>
<div>
<a:documentation>
Hardie, et al. Expires August 15, 2007 [Page 60]
Internet-Draft LoST February 2007
Expires pattern
</a:documentation>
<define name="expires">
<attribute name="expires">
<data type="dateTime"/>
</attribute>
</define>
</div>
<div>
<a:documentation>
A QName list
</a:documentation>
<define name="qnameList">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</define>
</div>
<div>
<a:documentation>
A location-to-service mapping.
</a:documentation>
<define name="mapping">
<element name="mapping">
<zeroOrMore>
<element name="displayName">
<data type="string"/>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</element>
</zeroOrMore>
<ref name="service" />
<optional>
<choice>
<ref name="serviceBoundary"/>
<ref name="serviceBoundaryReference"/>
</choice>
</optional>
<zeroOrMore>
<element name="uri">
Hardie, et al. Expires August 15, 2007 [Page 61]
Internet-Draft LoST February 2007
<data type="anyURI"/>
</element>
</zeroOrMore>
<optional>
<element name="serviceNumber">
<data type="string">
<param name="pattern">[0-9*#]+</param>
</data>
</element>
</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>
<element name="valid">
<ref name="qnameList" />
</element>
</optional>
<optional>
<element name="invalid">
<ref name="qnameList" />
</element>
</optional>
<optional>
<element name="unchecked">
<ref name="qnameList" />
Hardie, et al. Expires August 15, 2007 [Page 62]
Internet-Draft LoST February 2007
</element>
</optional>
<ref name="extensionPoint"/>
</element>
</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>
Hardie, et al. Expires August 15, 2007 [Page 63]
Internet-Draft LoST February 2007
<define name="errors">
<element name="errors">
<ref name="errorContainer" />
</element>
</define>
<define name="warnings">
<element name="warnings">
<ref name="errorContainer" />
</element>
</define>
</div>
<div>
<a:documentation>
Basic Errors
</a:documentation>
<define name="basicError">
<a:documentation>
Error pattern.
</a:documentation>
<ref name="message"/>
<ref name="extensionPoint" />
</define>
<define name="badRequest">
<element name="badRequest">
<ref name="basicError"/>
</element>
</define>
<define name="internalError">
<element name="internalError">
<ref name="basicError"/>
</element>
</define>
<define name="serviceSubstitution">
<element name="serviceSubstitution">
<ref name="basicError"/>
</element>
</define>
<define name="forbidden">
<element name="forbidden">
<ref name="basicError"/>
Hardie, et al. Expires August 15, 2007 [Page 64]
Internet-Draft LoST February 2007
</element>
</define>
<define name="notFound">
<element name="notFound">
<ref name="basicError"/>
</element>
</define>
<define name="loop">
<element name="loop">
<ref name="basicError" />
</element>
</define>
<define name="serviceNotImplemented">
<element name="serviceNotImplemented">
<ref name="basicError"/>
</element>
</define>
<define name="serverTimeout">
<element name="serverTimeout">
<ref name="basicError"/>
</element>
</define>
<define name="serverError">
<element name="serverError">
<ref name="basicError"/>
</element>
</define>
<define name="locationProfileUnrecognized">
<element name="locationProfileUnrecognized">
<attribute name="unsupportedProfiles">
<data type="NMTOKENS" />
</attribute>
<ref name="basicError"/>
</element>
</define>
</div>
<div>
<a:documentation>
Redirect.
</a:documentation>
Hardie, et al. Expires August 15, 2007 [Page 65]
Internet-Draft LoST February 2007
<define name="redirect">
<a:documentation>
Redirect pattern
</a:documentation>
<element name="redirect">
<attribute name="target">
<ref name="appUniqueString" />
</attribute>
<ref name="source" />
<ref name="message" />
<ref name="extensionPoint" />
</element>
</define>
</div>
<div>
<a:documentation>
Some common patterns.
</a:documentation>
<define name="message">
<optional>
<group>
<attribute name="message">
<data type="string"/>
</attribute>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</group>
</optional>
</define>
<define name="service">
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
</define>
<define name="appUniqueString">
<data type="string">
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
</data>
</define>
Hardie, et al. Expires August 15, 2007 [Page 66]
Internet-Draft LoST February 2007
<define name="source">
<attribute name="source">
<ref name="appUniqueString" />
</attribute>
</define>
<define name="serviceList" >
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI" />
</zeroOrMore>
</list>
</element>
</define>
</div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<define name="notLost">
<a:documentation>
Any element not in the LoST namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lost1"/>
<nsName/>
</except>
</anyName>
<ref name="anyElement"/>
</element>
</define>
<define name="anyElement">
<a:documentation>
A wildcard pattern for including any element
from any other namespace.
</a:documentation>
<zeroOrMore>
<choice>
<element>
Hardie, et al. Expires August 15, 2007 [Page 67]
Internet-Draft LoST February 2007
<anyName/>
<ref name="anyElement"/>
</element>
<attribute>
<anyName/>
</attribute>
<text/>
</choice>
</zeroOrMore>
</define>
<define name="extensionPoint">
<a:documentation>
A point where future extensions
(elements from other namespaces)
can be added.
</a:documentation>
<zeroOrMore>
<ref name="notLost" />
</zeroOrMore>
</define>
<define name="point2d">
<a:documentation>
A 2D point from GML.
</a:documentation>
<element name="Point" ns="http://www.opengis.net/gml">
<attribute name="srsName">
<value>urn:ogc:def:crs:EPSG::4326</value>
</attribute>
<ref name="pos"/>
</element>
</define>
<define name="pos">
<a:documentation>
A GML position
</a:documentation>
<element name="pos" ns="http://www.opengis.net/gml">
<list>
<data type="double"/>
</list>
</element>
</define>
<define name="linearRing">
<a:documentation>
A Linear Ring from GML.
Hardie, et al. Expires August 15, 2007 [Page 68]
Internet-Draft LoST February 2007
</a:documentation>
<element name="LinearRing"
ns="http://www.opengis.net/gml">
<ref name="pos"/>
<ref name="pos"/>
<ref name="pos"/>
<oneOrMore>
<ref name="pos"/>
</oneOrMore>
</element>
</define>
<define name="polygon">
<a:documentation>
A Polygon from GML.
</a:documentation>
<element name="Polygon"
ns="http://www.opengis.net/gml">
<attribute name="srsName">
<value>urn:ogc:def:crs:EPSG::4326</value>
</attribute>
<element name="exterior">
<ref name="linearRing"/>
</element>
<zeroOrMore>
<element name="interior">
<ref name="linearRing"/>
</element>
</zeroOrMore>
</element>
</define>
</div>
</grammar>
Figure 24
Hardie, et al. Expires August 15, 2007 [Page 69]
Internet-Draft LoST February 2007
Authors' Addresses
Ted Hardie
Qualcomm, Inc.
Email: hardie@qualcomm.com
Andrew Newton
SunRocket
8045 Leesburg Pike, Suite 300
Vienna, VA 22182
US
Phone: +1 703 636 0852
Email: andy@hxr.us
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Hardie, et al. Expires August 15, 2007 [Page 70]
Internet-Draft LoST February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hardie, et al. Expires August 15, 2007 [Page 71]
