Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc.
Intended status: Standards Track A. Newton
Expires: April 25, 2007 SunRocket
H. Schulzrinne
Columbia U.
H. Tschofenig
Siemens
October 22, 2006
LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-02.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 April 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Hardie, et al. Expires April 25, 2007 [Page 1]
Internet-Draft LoST October 2006
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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 8
5. LoST Uniform Resource Locators and Their Resolution . . . . . 9
6. Mapping a Location and Service to URLs: <findService> . . . . 10
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 10
6.2.2. Civic Address Mapping Example . . . . . . . . . . . . 11
6.3. Components of <findService> Request . . . . . . . . . . . 13
6.3.1. The <location> Element . . . . . . . . . . . . . . . . 13
6.3.2. The <service> Element . . . . . . . . . . . . . . . . 13
6.3.3. Recursion or Redirection . . . . . . . . . . . . . . . 13
6.3.4. Configuring the Response . . . . . . . . . . . . . . . 14
6.4. Components of the Mapping Response
<findServiceResponse> . . . . . . . . . . . . . . . . . . 16
6.4.1. Source of Response: <via> Element . . . . . . . . . . 16
6.4.2. Service URLs: the <uri> Element . . . . . . . . . . . 16
6.4.3. Describing the Service with the <displayName>
Element . . . . . . . . . . . . . . . . . . . . . . . 17
6.4.4. Approximating Services: the <service> Element . . . . 17
6.4.5. Defining the Service Region with the
<serviceBoundary> Element . . . . . . . . . . . . . . 17
6.4.6. Service Boundaries by Reference: the
<serviceBoundaryReference> Element . . . . . . . . . . 17
6.4.7. The Service Number . . . . . . . . . . . . . . . . . . 18
6.4.8. Civic Address Validation . . . . . . . . . . . . . . . 18
6.4.9. Validity: The 'timeToLive' Attribute . . . . . . . . . 18
7. Retrieving the Service Boundary via <getServiceBoundary> . . . 19
8. List Services: <listServices> . . . . . . . . . . . . . . . . 21
9. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 23
9.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 26
9.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 26
10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Basic Errors . . . . . . . . . . . . . . . . . . . . . . . 27
10.2. Response Errors . . . . . . . . . . . . . . . . . . . . . 27
Hardie, et al. Expires April 25, 2007 [Page 2]
Internet-Draft LoST October 2006
10.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 28
11. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 30
13. Internationalization Considerations . . . . . . . . . . . . . 37
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
14.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 38
14.2. Content-type registration for 'application/lost+xml' . . . 38
14.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 40
14.4. LoST Namespace Registration . . . . . . . . . . . . . . . 40
14.5. Registration Template . . . . . . . . . . . . . . . . . . 41
14.6. LoST Location Profile Registry . . . . . . . . . . . . . . 42
15. Security Considerations . . . . . . . . . . . . . . . . . . . 43
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
17. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
18.1. Normative References . . . . . . . . . . . . . . . . . . . 46
18.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Intellectual Property and Copyright Statements . . . . . . . . . . 62
Hardie, et al. Expires April 25, 2007 [Page 3]
Internet-Draft LoST October 2006
1. Introduction
This document describes a protocol for mapping a service identifier
[10] and location information compatible with PIDF-LO [8] to one or
more service contact URIs. Example contact URI 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" services 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 URIs and associated
information. LoST mapping queries can contain either civic or
geodetic location information. For civic addresses, LoST can
indicate which parts of the civic address are known to be valid or
invalid, thus providing address validation. LoST indicates errors in
the location data to facilitate debugging and proper user feedback,
but also provides best-effort answers.
LoST queries can be resolved recursively or iteratively. To minimize
round trips, LoST 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
protocol exchanges, facilitating use of TLS for protecting the
integrity and confidentiality of requests and responses.
This document focuses on the description of the protocol between the
mapping client (seeker or resolver) and the mapping server (resolver
or other servers). 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
itself, it may in turn query another server or return the address of
another LoST server, identified by a LoST URL (Section 5). In
addition to the mapping function described in Section 6, the protocol
also allows to retrieve the service boundary Section 7 and to list
Hardie, et al. Expires April 25, 2007 [Page 4]
Internet-Draft LoST October 2006
the services available for a particular location Section 8.
Hardie, et al. Expires April 25, 2007 [Page 5]
Internet-Draft LoST October 2006
2. 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].
Hardie, et al. Expires April 25, 2007 [Page 6]
Internet-Draft LoST October 2006
3. Terminology
This document furthermore uses the terminology defined in [18].
In examples, the XML sent by the client is prepended with "C:" and
the XML sent by the server is prepended with "S:".
Hardie, et al. Expires April 25, 2007 [Page 7]
Internet-Draft LoST October 2006
4. 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 BCP 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
according to their time-to-live value (see Section 6.4.9, or they
become invalid if the caller's device moves beyond the boundaries of
the service region.
Hardie, et al. Expires April 25, 2007 [Page 8]
Internet-Draft LoST October 2006
5. LoST Uniform Resource Locators and Their Resolution
LoST servers are identified by LoST Uniform Resource Locators (URLs),
which follow the format of URLs defined in RFC 3986 [7], with the
following ABNF:
LoST-URI = "lost:" host
'host' is defined in Section 3.2.2 of RFC 3986 [7].
An example is 'lost:lostserver.example.com'
If a LoST URL contains a host name rather than an IP address, clients
need to use U-NAPTR [12] using the U-NAPTR 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 resolve the LoST URL "lost:example.com"
to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL
http://lostserver.example.com, with the former being preferred.
example.com.
IN NAPTR 100 10 "u" "LoST:https"
"!*.!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http"
"!*.!http://lostserver.example.com!" ""
Hardie, et al. Expires April 25, 2007 [Page 9]
Internet-Draft LoST October 2006
6. Mapping a Location and Service to URLs: <findService>
6.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.
6.2. Examples
6.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" recursive="true"
include="uri service serviceNumber displayName serviceBoundary">
<location
profile="urn:ietf:params:lost:location-profile:geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>40.8089897 -73.9612492</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos.police</service>
</findService>
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:nypd@example.com and
xmpp:nypd@example.com. The server has also given the client a
geodetic, two-dimensional boundary for this service and time-to-live
value of 3,600 seconds. This instructs the client that if its
location changes beyond the give service boundary or if 3,600 seconds
has elapsed, it would need to requery for this information.
Hardie, et al. Expires April 25, 2007 [Page 10]
Internet-Draft LoST October 2006
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" timeToLive="3600">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</findServiceResponse>
Figure 3: A <findServiceResponse> Geodetic Answer
6.2.2. Civic Address Mapping Example
The following is an example of mapping a service to a location much
like the example in Section 6.2.1, but using civic address location
information. In this example, the client requests the service
associated with police (urn:service:sos.police) along with a specific
civic address (house number 96 on a street named Neu Perlach in
Munich, Germany).
Hardie, et al. Expires April 25, 2007 [Page 11]
Internet-Draft LoST October 2006
<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true"
include="uri serviceNumber displayName serviceBoundary" >
<location
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>
<A6>Neu Perlach</A6>
<HNO>96</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 Mȭnchen Polizei-Abteilung, instructing the client
that it may contact them via the URIs sip:munich-police@example.com
and xmpp:munich-police@example.com. The server has also given the
client a civic address boundary (the city of Munich) for this service
and time-to-live value of 3,600 seconds. This instructs the client
that if its location changes beyond the give service boundary (i.e.
beyond the city of Munich) or if 3,600 seconds has elapsed, it would
need to requery for this information.
Hardie, et al. Expires April 25, 2007 [Page 12]
Internet-Draft LoST October 2006
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600">
<displayName xml:lang="de">
Mȭnchen Polizei-Abteilung
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</findServiceResponse>
Figure 5: A <findServiceResponse> Civic Address Answer
6.3. Components of <findService> Request
6.3.1. The <location> Element
The <findService> query communicates location using one or more
<location> elements, which MUST conform to a location profile
(Section 9).
6.3.2. The <service> Element
The type of service desired is specified by the <service> element.
It contains service URNs from the registry established in [10].
6.3.3. Recursion or Redirection
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
Hardie, et al. Expires April 25, 2007 [Page 13]
Internet-Draft LoST October 2006
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.
Hardie, et al. Expires April 25, 2007 [Page 14]
Internet-Draft LoST October 2006
C: <?xml version="1.0" encoding="UTF-8"?>
C: <findService
C: xmlns="urn:ietf:params:xml:ns:lost1"
C: recursive="true"
C: include="uri serviceNumber invalid valid unchecked">
C: <location
C: profile="urn:ietf:params:lost:location-profile:basic-civic">
C: <civicAddress
C: xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
C: <country>Germany</country>
C: <A1>Bavaria</A1>
C: <A3>Munich</A3>
C: <A6>Neu Perlach</A6>
C: <HNO>96</HNO>
C: <PC>81675</PC>
C: </civicAddress>
C: </location>
C: <service>urn:service:sos.police</service>
C: </findService>
S: <?xml version="1.0" encoding="UTF-8"?>
S: <findServiceResponse
S: xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600">
S: <displayName xml:lang="de">
S: Mȭnchen Polizei-Abteilung
S: </displayName>
S: <service>urn:service:sos.police</service>
S: <serviceBoundary
S: profile="urn:ietf:params:lost:location-profile:basic-civic">
S: <civicAddress
S: xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
S: <country>Germany</country>
S: <A1>Bavaria</A1>
S: <A3>Munich</A3>
S: <PC>81675</PC>
S: </civicAddress>
S: </serviceBoundary>
S: <uri>sip:munich-police@example.com</uri>
S: <uri>xmpp:munich-police@example.com</uri>
S: <serviceNumber>110</serviceNumber>
S: <valid>country A1 A3 A6</valid>
S: <invalid>PC</invalid>
S: </findServiceResponse>
Figure 6: Address Validation Exchange
Hardie, et al. Expires April 25, 2007 [Page 15]
Internet-Draft LoST October 2006
6.4. Components of the Mapping Response <findServiceResponse>
6.4.1. Source of Response: <via> Element
A <findServiceResponse> indicates the source of the response by
including a <via> element with a LoST URL as the first <via> element.
Thus, each server "initials" its own response. Thus, responses to
iterative queries contain one <via> element, while responses to
recursive queries may reach the original querier with multiple <via>
elements, one for each server that was used in the resolution. The
following <findServiceResponse> example illustrates the use of <via>:
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600">
<via>lost:esgw.uber-110.de.example</via>
<via>lost:polizei.munchen.de.example</via>
<displayName xml:lang="de">
Mȭnchen Polizei-Abteilung
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</findServiceResponse>
Figure 7: An Example of a Response Using <via>
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.
Hardie, et al. Expires April 25, 2007 [Page 16]
Internet-Draft LoST October 2006
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.
Hardie, et al. Expires April 25, 2007 [Page 17]
Internet-Draft LoST October 2006
The identifier is a random token with at least 128 bits of entropy
and can be assumed to be globally unique. The identifier uniquely
references a particular boundary; if the boundary changes, a new
identifier must be chosen. Because of these properties, a client
receiving a mapping response can simply check if it already has a
copy of the boundary with that identifier. If so, it can skip
checking with the server whether the boundary has been updated.
Since service boundaries are likely to remain unchanged for extended
periods of time, possibly exceeding the normal lifetime of the
service URL, this approach avoids refreshing the boundary information
even if the cached service response has gotten stale.
6.4.7. 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.
6.4.8. Civic Address Validation
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. 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.
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.
6.4.9. Validity: The 'timeToLive' Attribute
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.]
Hardie, et al. Expires April 25, 2007 [Page 18]
Internet-Draft LoST October 2006
7. Retrieving the Service Boundary via <getServiceBoundary>
As discussed in Section 6.4.5, the <findService> response can return
a globally unique identifier that can be used to retrieve the service
boundary, rather than returning the boundary by value. This is shown
in the example in Figure 8. The client can then retrieve the
boundary using the <getServiceBoundary> request and obtains the
boundary in the <getServiceBoundaryResponse>, illustrated in the
example in Section 7. The client issues the request to the server
identified in the 'server' attribute of the
<serviceBoundaryReference> element.
C: <?xml version="1.0" encoding="UTF-8"?>
C: <findService xmlns="urn:ietf:params:xml:ns:lost1"
C: xmlns:p2="http://www.opengis.net/gml" recursive="true"
C: include="uri service serviceNumber displayName
C: serviceBoundaryReference">
C: <location
C: profile="urn:ietf:params:lost:location-profile:geodetic-2d">
C: <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
C: <p2:pos>40.809 -73.9612</p2:pos>
C: </p2:Point>
C: </location>
C: <service>urn:service:sos.police</service>
C: </findService>
S: <?xml version="1.0" encoding="UTF-8"?>
S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
S: timeToLive="3600">
S: <displayName xml:lang="en">
S: New York City Police Department
S: </displayName>
S: <service>urn:service:sos.police</service>
S: <serviceBoundaryReference server="lost:nypd.example.com"
S: key="7214148E0433AFE2FA2D48003D31172E"/>
S: <uri>sip:nypd@example.com</uri>
S: <uri>xmpp:nypd@example.com</uri>
S: <serviceNumber>911</serviceNumber>
S: </findServiceResponse>
Figure 8: findService with Service Boundary Reference
Hardie, et al. Expires April 25, 2007 [Page 19]
Internet-Draft LoST October 2006
C: <?xml version="1.0" encoding="UTF-8"?>
C: <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
C: key="7214148E0433AFE2FA2D48003D31172E"/>
S: <?xml version="1.0" encoding="UTF-8"?>
S: <getServiceBoundaryResponse
S: xmlns="urn:ietf:params:xml:ns:lost1"
S: xmlns:p2="http://www.opengis.net/gml">
S:
S: <serviceBoundary
S: profile="urn:ietf:params:lost:location-profile:geodetic-2d">
S: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
S: <p2:exterior>
S: <p2:LinearRing>
S: <p2:pos>40.701 -74.020</p2:pos>
S: <p2:pos>40.876 -73.926</p2:pos>
S: <p2:pos>40.797 -73.936</p2:pos>
S: <p2:pos>40.714 -73.984</p2:pos>
S: <p2:pos>40.701 -74.020</p2:pos>
S: </p2:LinearRing>
S: </p2:exterior>
S: </p2:Polygon>
S: </serviceBoundary>
S:
S: </getServiceBoundaryResponse>
Figure 9: 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 10.
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
</civicAddress>
</serviceBoundary>
</getServiceBoundaryResponse>
Figure 10: Civic Address Service Boundary Response
Hardie, et al. Expires April 25, 2007 [Page 20]
Internet-Draft LoST October 2006
8. List Services: <listServices>
A LoST client can ask a LoST server for the list of services it
supports. The <listServices> query contains one or more <location>
elements, each from a different location profile (Section 9), and may
contain the <service> element. If the query contains the <service>
element the LoST server returns only immediate child services of the
queried service that are available for the provided location. If the
<service> element is absent, the LoST service returns all top-level
services available for the provided location that it knows about.
A server responds to this query with a <listServicesResponse>
response. This response has may contain <via> elements
(Section 6.4.1) and must contain a <serviceList> element, consisting
of a whitespace-separated list of service URNs. The query and
response are illustrated in Figure 11.
C: <?xml version="1.0" encoding="UTF-8"?>
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"?>
S: <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1">
S: <serviceList>
S: urn:service:sos.ambulance
S: urn:service:sos.animal-control
S: urn:service:sos.fire
S: urn:service:sos.gas
S: urn:service:sos.mountain
S: urn:service:sos.marine
S: urn:service:sos.physician
S: urn:service:sos.poison
S: urn:service:sos.police
S: urn:service:sos.suicide
S: </serviceList>
S: </listServicesResponse>
Hardie, et al. Expires April 25, 2007 [Page 21]
Internet-Draft LoST October 2006
Figure 11: ListService Query Example
Hardie, et al. Expires April 25, 2007 [Page 22]
Internet-Draft LoST October 2006
9. Location Profiles
Currently, LoST uses location information in <location> elements in
requests and <serviceBoundary> elements in responses. Such location
information may be expressed in a variety of ways. This variety can
cause interoperability problems where a request or response contains
location information in a format not understood by the server or
client, respectively. To achieve interoperability, LoST defines two
must-implement baseline location profiles to define the manner in
which location information is transmitted and makes it possible to
standardize other profiles in the future. The two baseline profiles
are:
geodetic-2d: a simple profile for two-dimensional geodetic location
information, described in Section 9.2);
civic: a profile consisting of civic address location information,
described in Section 9.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 may create other 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
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.
9.1. Location Profile Usage
A location profile is identified by a URN in the
urn:ietf:params:lost:location-profile registry. (Note that this is
not an XML schema or namespace identifier.) Clients send location
Hardie, et al. Expires April 25, 2007 [Page 23]
Internet-Draft LoST October 2006
information compliant with a location profile, and servers respond
with location information compliant with that same location profile.
When a LoST client sends a request which provides location
information, it contains one or more <location> elements. Each of
these elements contains location information compliant with a
location profile and specifies which profile has been used in the
'profile' attribute. This allows the client to convey location
information for multiple location profiles in the same request.
When a LoST server sends a response which contains location
information, it uses the <serviceBoundary> elements much like the
client uses the <location> elements. Each <serviceBoundary> element
contains location information conformant to the location profile
specified in the 'profile' attribute. This allows the server to send
location information compliant with multiple location profiles.
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. Servers MUST implement the geodetic-2d and civic profiles.
4. A server ignores any location information using non-baseline
profiles it does not understand.
5. If a server receives a request that only contains location
information using profiles it does not understand, the server
responds with a <locationProfileError> (Section 10.2).
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
Hardie, et al. Expires April 25, 2007 [Page 24]
Internet-Draft LoST October 2006
both Client X and Server Y understand the baseline profile. The
following transaction, where the XML sent by the client is prepended
with 'C:' and the XML sent by the server is prepended with 'S:',
demonstrates this:
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"?>
S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
S: xmlns:p2="http://www.opengis.net/" timeToLive="3600">
S: <locationProfileError
S: unsupportedProfiles="
S: urn:ietf:params:lost:location-profile:uber-complex-3d"
S: message="Too sophisticated for us." xml:lang="en"/>
S: <displayName xml:lang="en">
S: New York City Police Department
S: </displayName>
S: <service>urn:service:sos.police</service>
S: <serviceBoundary
S: profile="urn:ietf:params:lost:location-profile:geodetic-2d">
Hardie, et al. Expires April 25, 2007 [Page 25]
Internet-Draft LoST October 2006
S: <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
S: <p2:exterior>
S: <p2:LinearRing>
S: <p2:pos>40.701 -74.020</p2:pos>
S: <p2:pos>40.876 -73.926</p2:pos>
S: <p2:pos>40.797 -73.936</p2:pos>
S: <p2:pos>40.714 -73.984</p2:pos>
S: <p2:pos>40.701 -74.020</p2:pos>
S: </p2:LinearRing>
S: </p2:exterior>
S: </p2:Polygon>
S: </serviceBoundary>
S: <uri>sip:nypd@example.com</uri>
S: </findServiceResponse>
Figure 12: Example of a findServices query with baseline profile
interoperability
9.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 12).
Servers use this profile by placing a GML [13] <Polygon> element
within the <serviceBoundary> element. This is defined by the
'polygon' pattern in the LoST schema (see Section 12).
9.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 April 25, 2007 [Page 26]
Internet-Draft LoST October 2006
10. Error Handling
Errors are indicated by error-specific elements. Depending on the
nature of the error, the error element may occur along with other
response elements, indicating that the request was only partially
satisfied and that not all information in the request was processed
correctly. Errors labeled as fatal means
10.1. Basic Errors
LoST defines a pattern for errors, defined as "errors" 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.
LoST defines the following elements as following this pattern:
badRequest The server could not parse or otherwise understand a
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.
See Section 6.4.4.
10.2. Response Errors
LoST defines a pattern for errors that may generated by referrent
LoST serves queried on behalf of seekers by a resolving LoST server.
This pattern builds on the basic errors pattern (Section 10.1). It
also provides the option of specifying the source server using the
'source' attribute, as well as specifying the query that caused the
error.
LoST defines the following elements as following this pattern:
forbidden The server refused to send an answer.
notFound The server could not find an answer to the query.
serviceNotImplemented The requested service is not implemented.
internalError The server could not satisfy a request due to
misconfiguration or other operational and non-protocol related
reasons.
Hardie, et al. Expires April 25, 2007 [Page 27]
Internet-Draft LoST October 2006
serverTimeout A time out occurred before an answer was received.
serverError An answer was received but it could not be parsed or
otherwise understood.
locationProfileError A location profile in the query given is not
recognized. The element may also have an 'unsupportedProfiles'
attribute, which contains a whitespace separated list of profile
URNs. See Section 9.
10.3. Redirects
LoST defines a pattern for redirect responses. This pattern builds
on the basic error pattern (Section 10.1) and includes a 'url'
attribute indicating the LoST URL that the client should be
contacting next.
Currently, LoST only defines the <redirect> element along this
pattern.
Hardie, et al. Expires April 25, 2007 [Page 28]
Internet-Draft LoST October 2006
11. LoST Transport
LoST needs an underlying protocol transport mechanisms to carry
requests and responses. This document defines the use of LoST over
HTTP and HTTP-over-TLS; other mechanisms are left to future
documents. The available transport mechanisms are determined through
the use of the LoST U-NAPTR application. In protocols that support
content type indication, LoST uses the media type application/
lost+xml.
When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP
POST method. All HTTP responses are applicable. The HTTP URL is
derived from the LoST URL via U-NAPTR application, as discussed in
Section 5.
Hardie, et al. Expires April 25, 2007 [Page 29]
Internet-Draft LoST October 2006
12. 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
| getServiceBoundary
| findServiceResponse
| listServicesResponse
| getServiceBoundaryResponse
##
## The queries.
##
div {
findService =
element ns1:findService {
query,
attribute include {
list {
("uri"
| "serviceNumber"
| "displayName"
| "service"
| "valid"
| "invalid"
| "unchecked"
| "serviceBoundary"
| "serviceBoundaryReference")*
}
>> a:defaultValue [ "uri serviceNumber" ]
}?
}
Hardie, et al. Expires April 25, 2007 [Page 30]
Internet-Draft LoST October 2006
listServices = element ns1:listServices { query }
getServiceBoundary =
element ns1:getServiceBoundary {
serviceBoundaryKey, extensionPoint
}
}
##
## The responses.
##
div {
findServiceResponse =
element ns1:findServiceResponse {
via,
((locationProfileError?, serviceSubstitution?, serviceResult)
| badRequest
| internalError
| forbidden
| notFound
| serviceNotImplemented
| serverTimeout
| serverError
| movedPermenantly
| movedTemporarily
| iterativeSearchExhausted),
extensionPoint
}
listServicesResponse =
element ns1:listServicesResponse {
via,
((locationProfileError?,
element ns1:serviceList {
list { xsd:anyURI* }
})),
extensionPoint
}
getServiceBoundaryResponse =
element ns1:getServiceBoundaryResponse {
(serviceBoundary
| badRequest
| internalError
| forbidden
| notFound),
extensionPoint
}
}
##
Hardie, et al. Expires April 25, 2007 [Page 31]
Internet-Draft LoST October 2006
## A pattern common to some of the queries.
##
div {
query =
element ns1:location { locationInformation }+,
element ns1:service { xsd:anyURI }?,
extensionPoint,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:anyURI }
}
##
## Service Boundary
##
div {
serviceBoundary = element ns1:serviceBoundary
{ locationInformation }+
}
##
## Service Boundary Key
##
div {
serviceBoundaryKey =
attribute key {
xsd:string { pattern = "[a-zA-Z0-9/+=]+" }
}
}
##
## Via - list of places through which information flowed
##
div {
via = element ns1:via { xsd:anyURI }*
}
##
## Time-to-live pattern
##
div {
Hardie, et al. Expires April 25, 2007 [Page 32]
Internet-Draft LoST October 2006
timeToLive = attribute timeToLive { xsd:positiveInteger }
}
##
## A QName list
##
div {
qnameList = list { xsd:QName* }
}
##
## A location-to-service result.
##
div {
serviceResult =
element ns1:displayName {
xsd:string,
attribute xml:lang { xsd:language }
}?,
element ns1:service { xsd:anyURI }?,
(serviceBoundary
| element ns1:serviceBoundaryReference { serviceBoundaryKey })?,
element ns1:uri { xsd:anyURI }*,
element ns1:serviceNumber {
xsd:string { pattern = "[0-9]+" }
}?,
element ns1:valid { qnameList }?,
element ns1:invalid { qnameList }?,
element ns1:unchecked { qnameList }?,
extensionPoint,
timeToLive,
message
}
##
## Basic Errors
##
div {
##
## Error pattern.
##
error = message, extensionPoint
badRequest = element ns1:badRequest { error }
internalError = element ns1:internalError { error }
serviceSubstitution = element ns1:serviceSubstitution { error }
}
Hardie, et al. Expires April 25, 2007 [Page 33]
Internet-Draft LoST October 2006
##
## Recursion Errors.
##
div {
##
## Recursion error.
##
recursionError =
attribute failedReferral { xsd:anyURI }?,
(findService | listServices | getServiceBoundary)?,
error
forbidden =
element ns1:forbidden { recursionError },
timeToLive
notFound =
element ns1:notFound { recursionError },
timeToLive
serviceNotImplemented =
element ns1:serviceNotImplemented { recursionError },
timeToLive
serverTimeout =
element ns1:serverTimeout { recursionError },
timeToLive
serverError =
element ns1:serverError { recursionError },
timeToLive
locationProfileError =
element ns1:locationProfileError {
attribute unsupportedProfiles {
list { xsd:anyURI* }
},
recursionError
}
}
##
## Redirects.
##
div {
##
## Redirect pattern
##
redirect =
attribute redirect { xsd:anyURI },
error
movedPermenantly = element ns1:movedPermanently { redirect }
Hardie, et al. Expires April 25, 2007 [Page 34]
Internet-Draft LoST October 2006
movedTemporarily =
element ns1:movedTemporarily { redirect },
timeToLive
iterativeSearchExhausted =
element ns1:iterativeSearchExhausted { redirect },
timeToLive
}
##
## Message pattern.
##
div {
message =
(attribute message { xsd:string },
attribute xml:lang { xsd:language })?
}
##
## 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)*
##
## A point where future extensions
## (elements from other namespaces)
## can be added.
##
extensionPoint = notLost*
##
## A 2D point from GML.
##
point2d =
Hardie, et al. Expires April 25, 2007 [Page 35]
Internet-Draft LoST October 2006
element position {
element Point {
attribute srsName { "urn:ogc:def:crs:EPSG:4326" },
element pos { text }
}
}
##
## A Linear Ring from GML.
##
linearRing =
element LinearRing {
element pos { text }
}
##
## A Polygon from GML.
##
polygon =
element Polygon {
attribute srsName { "urn:ogc:def:crs:EPSG:4979" },
element exterior { linearRing },
element interior { linearRing }*
}
}
Hardie, et al. Expires April 25, 2007 [Page 36]
Internet-Draft LoST October 2006
13. 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 April 25, 2007 [Page 37]
Internet-Draft LoST October 2006
14. IANA Considerations
14.1. U-NAPTR Registrations
This document registers the following U-NAPTR application service
tag:
Application Service Tag: LoST
Defining Publication: The specification contained within this
document.
This document registers the following U-NAPTR application protocol
tags:
o
Application Protocol Tag: http
Defining Publication: RFC 2616 [3]
o
Application Protocol Tag: https
Defining Publication: RFC 2818 [5]
14.2. Content-type registration for 'application/lost+xml'
This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [9] and guidelines in RFC
3023 [6].
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 April 25, 2007 [Page 38]
Internet-Draft LoST October 2006
Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See RFC 3023 [6], 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 April 25, 2007 [Page 39]
Internet-Draft LoST October 2006
Change controller:
The IESG <iesg@ietf.org>
14.3. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:lost
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 12. Its first line is
default namespace = "urn:ietf:params:xml:ns:lost1"
and its last line is
}
14.4. LoST Namespace Registration
URI: urn:ietf:params:xml:ns:lost
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
XML:
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:lost</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>
Hardie, et al. Expires April 25, 2007 [Page 40]
Internet-Draft LoST October 2006
END
14.5. Registration Template
This registration template is in accordance with [4].
URL scheme name:
lost
URL scheme syntax:
See Section 5
Character encoding considerations:
See Section 5
Intended Use:
The intended usage is described in this document.
Application and protocols which use this scheme:
The usage of the LoST URL scheme is targeted for this document and
hence for location-based services that make use of the mapping
protocol specified in this document.
Interoperability considerations:
None
Security considerations:
See Section 15
Relevant publications:
This document provides the relevant context for this URL scheme.
Hardie, et al. Expires April 25, 2007 [Page 41]
Internet-Draft LoST October 2006
Contact:
Hannes Tschofenig, Hannes.Tschofenig@siemens.com
Author/Change controller:
The IESG <iesg@ietf.org>
14.6. LoST Location Profile Registry
This document seeks to create a registry of location profile names
for the LoST protocol. Profile names are XML tokens. This registry
will operate in accordance with RFC 2434 [2], Standards Action.
geodetic-2d: Defined in TBD
civic: Defined in TBD
Hardie, et al. Expires April 25, 2007 [Page 42]
Internet-Draft LoST October 2006
15. 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 channels security, such as TLS, is RECOMMENDED.
A more detailed description of threats and security requirements are
provided in [17].
Hardie, et al. Expires April 25, 2007 [Page 43]
Internet-Draft LoST October 2006
16. Acknowledgments
[Editor's Note: Names need to be added here. Forgot it...Sorry.]
Hardie, et al. Expires April 25, 2007 [Page 44]
Internet-Draft LoST October 2006
17. Open Issues
Please find open issues at: http://www.ietf-ecrit.org:8080/lost/
Hardie, et al. Expires April 25, 2007 [Page 45]
Internet-Draft LoST October 2006
18. References
18.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] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, November 1999.
[5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[8] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[9] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[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-00 (work in progress), June 2006.
[13] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC OGC 02-023r4, January 2003.
Hardie, et al. Expires April 25, 2007 [Page 46]
Internet-Draft LoST October 2006
18.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-00 (work in
progress), August 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 April 25, 2007 [Page 47]
Internet-Draft LoST October 2006
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="getServiceBoundary" />
<ref name="findServiceResponse" />
<ref name="listServicesResponse" />
<ref name="getServiceBoundaryResponse" />
</choice>
</start>
<div>
<a:documentation>
The queries.
</a:documentation>
<define name="findService">
<element name="findService">
<ref name="query" />
<optional>
<attribute name="include">
<list>
<zeroOrMore>
<choice>
<value>uri</value>
<value>serviceNumber</value>
<value>displayName</value>
<value>service</value>
<value>valid</value>
<value>invalid</value>
<value>unchecked</value>
<value>serviceBoundary</value>
Hardie, et al. Expires April 25, 2007 [Page 48]
Internet-Draft LoST October 2006
<value>serviceBoundaryReference</value>
</choice>
</zeroOrMore>
</list>
<a:defaultValue>uri serviceNumber</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="listServices">
<element name="listServices">
<ref name="query" />
</element>
</define>
<define name="getServiceBoundary">
<element name="getServiceBoundary">
<ref name="serviceBoundaryKey" />
<ref name="extensionPoint" />
</element>
</define>
</div>
<div>
<a:documentation>
The responses.
</a:documentation>
<define name="findServiceResponse">
<element name="findServiceResponse ">
<ref name="via" />
<choice>
<group>
<optional>
<ref name="locationProfileError"/>
</optional>
<optional>
<ref name="serviceSubstitution"/>
</optional>
<ref name="serviceResult" />
</group>
<ref name="badRequest"/>
<ref name="internalError"/>
<ref name="forbidden"/>
<ref name="notFound"/>
Hardie, et al. Expires April 25, 2007 [Page 49]
Internet-Draft LoST October 2006
<ref name="serviceNotImplemented"/>
<ref name="serverTimeout"/>
<ref name="serverError"/>
<ref name="movedPermenantly"/>
<ref name="movedTemporarily"/>
<ref name="iterativeSearchExhausted"/>
</choice>
<ref name="extensionPoint" />
</element>
</define>
<define name="listServicesResponse">
<element name="listServicesResponse">
<ref name="via" />
<choice>
<group>
<optional>
<ref name="locationProfileError"/>
</optional>
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI" />
</zeroOrMore>
</list>
</element>
</group>
</choice>
<ref name="extensionPoint" />
</element>
</define>
<define name="getServiceBoundaryResponse">
<element name="getServiceBoundaryResponse">
<choice>
<group>
<ref name="serviceBoundary"/>
</group>
<ref name="badRequest"/>
<ref name="internalError"/>
<ref name="forbidden"/>
<ref name="notFound"/>
</choice>
<ref name="extensionPoint" />
</element>
</define>
Hardie, et al. Expires April 25, 2007 [Page 50]
Internet-Draft LoST October 2006
</div>
<div>
<a:documentation>
A pattern common to some of the queries.
</a:documentation>
<define name="query">
<oneOrMore>
<element name="location">
<ref name="locationInformation" />
</element>
</oneOrMore>
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
<ref name="extensionPoint" />
<optional>
<attribute name="recursive">
<data type="boolean" />
<a:defaultValue>true</a:defaultValue>
</attribute>
</optional>
</define>
</div>
<div>
<a:documentation>
Location Information
</a:documentation>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<attribute name="profile">
<data type="anyURI" />
</attribute>
</define>
</div>
<div>
<a:documentation>
Service Boundary
</a:documentation>
Hardie, et al. Expires April 25, 2007 [Page 51]
Internet-Draft LoST October 2006
<define name="serviceBoundary">
<oneOrMore>
<element name="serviceBoundary">
<ref name="locationInformation" />
</element>
</oneOrMore>
</define>
</div>
<div>
<a:documentation>
Service Boundary Key
</a:documentation>
<define name="serviceBoundaryKey">
<attribute name="key">
<data type="string">
<param name="pattern">[a-zA-Z0-9/+=]+</param>
</data>
</attribute>
</define>
</div>
<div>
<a:documentation>
Via - list of places through which information flowed
</a:documentation>
<define name="via">
<zeroOrMore>
<element name="via">
<data type="anyURI"/>
</element>
</zeroOrMore>
</define>
</div>
<div>
<a:documentation>
Time-to-live pattern
</a:documentation>
<define name="timeToLive">
<attribute name="timeToLive">
<data type="positiveInteger"/>
</attribute>
</define>
</div>
Hardie, et al. Expires April 25, 2007 [Page 52]
Internet-Draft LoST October 2006
<div>
<a:documentation>
A QName list
</a:documentation>
<define name="qnameList">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</define>
</div>
<div>
<a:documentation>
A location-to-service result.
</a:documentation>
<define name="serviceResult">
<optional>
<element name="displayName">
<data type="string"/>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</element>
</optional>
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
<optional>
<choice>
<ref name="serviceBoundary"/>
<element name="serviceBoundaryReference">
<ref name="serviceBoundaryKey"/>
</element>
</choice>
</optional>
<zeroOrMore>
<element name="uri">
<data type="anyURI"/>
</element>
</zeroOrMore>
<optional>
<element name="serviceNumber">
Hardie, et al. Expires April 25, 2007 [Page 53]
Internet-Draft LoST October 2006
<data type="string">
<param name="pattern">[0-9]+</param>
</data>
</element>
</optional>
<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" />
</element>
</optional>
<ref name="extensionPoint"/>
<ref name="timeToLive"/>
<ref name="message"/>
</define>
</div>
<div>
<a:documentation>
Basic Errors
</a:documentation>
<define name="error">
<a:documentation>
Error pattern.
</a:documentation>
<ref name="message"/>
<ref name="extensionPoint" />
</define>
<define name="badRequest">
<element name="badRequest">
<ref name="error"/>
</element>
</define>
<define name="internalError">
<element name="internalError">
Hardie, et al. Expires April 25, 2007 [Page 54]
Internet-Draft LoST October 2006
<ref name="error"/>
</element>
</define>
<define name="serviceSubstitution">
<element name="serviceSubstitution">
<ref name="error"/>
</element>
</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">
<element name="forbidden">
<ref name="recursionError"/>
</element>
<ref name="timeToLive"/>
</define>
<define name="notFound">
<element name="notFound">
<ref name="recursionError"/>
</element>
<ref name="timeToLive"/>
Hardie, et al. Expires April 25, 2007 [Page 55]
Internet-Draft LoST October 2006
</define>
<define name="serviceNotImplemented">
<element name="serviceNotImplemented">
<ref name="recursionError"/>
</element>
<ref name="timeToLive"/>
</define>
<define name="serverTimeout">
<element name="serverTimeout">
<ref name="recursionError"/>
</element>
<ref name="timeToLive"/>
</define>
<define name="serverError">
<element name="serverError">
<ref name="recursionError"/>
</element>
<ref name="timeToLive"/>
</define>
<define name="locationProfileError">
<element name="locationProfileError">
<attribute name="unsupportedProfiles">
<list>
<zeroOrMore>
<data type="anyURI"/>
</zeroOrMore>
</list>
</attribute>
<ref name="recursionError"/>
</element>
</define>
</div>
<div>
<a:documentation>
Redirects.
</a:documentation>
<define name="redirect">
<a:documentation>
Redirect pattern
</a:documentation>
<attribute name="redirect">
Hardie, et al. Expires April 25, 2007 [Page 56]
Internet-Draft LoST October 2006
<data type="anyURI"/>
</attribute>
<ref name="error"/>
</define>
<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>
<ref name="timeToLive" />
</define>
</div>
<div>
<a:documentation>
Message pattern.
</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>
</div>
<div>
Hardie, et al. Expires April 25, 2007 [Page 57]
Internet-Draft LoST October 2006
<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>
<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" />
Hardie, et al. Expires April 25, 2007 [Page 58]
Internet-Draft LoST October 2006
</zeroOrMore>
</define>
<define name="point2d">
<a:documentation>
A 2D point from GML.
</a:documentation>
<element name="position" ns="http://www.opengis.net/gml">
<element name="Point">
<attribute name="srsName">
<value>urn:ogc:def:crs:EPSG:4326</value>
</attribute>
<element name="pos">
<text/>
</element>
</element>
</element>
</define>
<define name="linearRing">
<a:documentation>
A Linear Ring from GML.
</a:documentation>
<element name="LinearRing" ns="http://www.opengis.net/gml">
<element name="pos">
<text/>
</element>
</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:4979</value>
</attribute>
<element name="exterior">
<ref name="linearRing"/>
</element>
<zeroOrMore>
<element name="interior">
<ref name="linearRing"/>
</element>
</zeroOrMore>
</element>
</define>
Hardie, et al. Expires April 25, 2007 [Page 59]
Internet-Draft LoST October 2006
</div>
</grammar>
Hardie, et al. Expires April 25, 2007 [Page 60]
Internet-Draft LoST October 2006
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
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 April 25, 2007 [Page 61]
Internet-Draft LoST October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 April 25, 2007 [Page 62]
