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 © The Internet Society (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
2.  Requirements Notation
3.  Terminology
4.  Overview of Protocol Usage
5.  LoST Uniform Resource Locators and Their Resolution
6.  Mapping a Location and Service to URLs: <findService>
    6.1.  Overview
    6.2.  Examples
        6.2.1.  Example Using Geodetic Coordinates
        6.2.2.  Civic Address Mapping Example
    6.3.  Components of <findService> Request
        6.3.1.  The <location> Element
        6.3.2.  The <service> Element
        6.3.3.  Recursion or Redirection
        6.3.4.  Configuring the Response
    6.4.  Components of the Mapping Response <findServiceResponse>
        6.4.1.  Source of Response: <via> Element
        6.4.2.  Service URLs: the <uri> Element
        6.4.3.  Describing the Service with the <displayName> Element
        6.4.4.  Approximating Services: the <service> Element
        6.4.5.  Defining the Service Region with the <serviceBoundary> Element
        6.4.6.  Service Boundaries by Reference: the <serviceBoundaryReference> Element
        6.4.7.  The Service Number
        6.4.8.  Civic Address Validation
        6.4.9.  Validity: The 'timeToLive' Attribute
7.  Retrieving the Service Boundary via <getServiceBoundary>
8.  List Services: <listServices>
9.  Location Profiles
    9.1.  Location Profile Usage
    9.2.  Two Dimensional Geodetic Profile
    9.3.  Basic Civic Profile
10.  Error Handling
    10.1.  Basic Errors
    10.2.  Response Errors
    10.3.  Redirects
11.  LoST Transport
12.  Relax NG Schema
13.  Internationalization Considerations
14.  IANA Considerations
    14.1.  U-NAPTR Registrations
    14.2.  Content-type registration for 'application/lost+xml'
    14.3.  LoST Relax NG Schema Registration
    14.4.  LoST Namespace Registration
    14.5.  Registration Template
    14.6.  LoST Location Profile Registry
15.  Security Considerations
16.  Acknowledgments
17.  Open Issues
18.  References
    18.1.  Normative References
    18.2.  Informative References
Appendix A.  Non-Normative RELAX NG Schema in XML Syntax
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

This document describes a protocol for mapping a service identifier [10] (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.) and location information compatible with PIDF-LO (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) [8] to one or more service contact URIs. Example contact URI schemes include sip [14] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), xmpp [15] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.), and tel [16] (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.). 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] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” August 2006.) 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] (Schulzrinne, H., “Location-to-URL Mapping Architecture and Framework,” August 2006.).

The query message carries location information and a service identifier encoded as a Uniform Resource Name (URN) (see [10] (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.)) 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 (LoST Uniform Resource Locators and Their Resolution). In addition to the mapping function described in Section 6 (Mapping a Location and Service to URLs: <findService>), the protocol also allows to retrieve the service boundary Section 7 (Retrieving the Service Boundary via <getServiceBoundary>) and to list the services available for a particular location Section 8 (List Services: <listServices>).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Terminology

This document furthermore uses the terminology defined in [18] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” August 2006.).

In examples, the XML sent by the client is prepended with "C:" and the XML sent by the server is prepended with "S:".

4.  Overview of Protocol Usage

The client may perform the mapping at any time. Among the common 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] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” October 2006.) 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 (Validity: The 'timeToLive' Attribute), or they become invalid if the caller's device moves beyond the boundaries of the service region.

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] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.), with the following ABNF:

LoST-URI = "lost:" host

'host' is defined in Section 3.2.2 of RFC 3986 [7] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).

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] (Daigle, L., “Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS),” June 2006.) 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!"  ""

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>

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.

<?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>

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 (Example Using Geodetic Coordinates), but using civic address location information. In this example, the client requests the service associated with police (urn:service:sos.police) along with a specific civic address (house number 96 on a street named Neu Perlach in Munich, Germany).

<?xml version="1.0" encoding="UTF-8"?>
<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>

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.

<?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>

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 (Location Profiles)).

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] (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.).

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> (Redirects) error message with the LoST URI pointing to a different LoST server that the LoST client should contact. In recursive mode, the LoST server initiates a query and returns the result to the original querier, inserting a <via> element to track the response chain.

6.3.4.  Configuring the Response

The 'include' attribute enumerates all the XML elements that the client wants the LoST server to provide in the mapping response. The server ignores any element names that it does not understand. The ordering of the tokens is immaterial.

Among other features, it determines whether service boundaries are returned and whether they are returned by value or reference Section 7 (Retrieving the Service Boundary via <getServiceBoundary>), and whether to validate civic locations.

Address validation is requested by including the XML element names that provide address validation in the 'include' attribute, namely 'valid', 'invalid' and 'unchecked'. The following example demonstrates address validation.

C: <?xml version="1.0" encoding="UTF-8"?>
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>

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>

The example above indicates that the this answer was given to the responding server by the LoST server at esgw.uber-110.de.example, which got the answer from the LoST server at polizei.munchen.de.example.

6.4.2.  Service URLs: the <uri> Element

The response returns the service URLs in one or more <uri> elements. The URLs MUST be absolute URLs.

6.4.3.  Describing the Service with the <displayName> Element

The <displayName> element describes the service with a string that is suitable for display to human users, annotated with the 'xml:lang' attribute that contains a language tag to aid in the rendering of text.

6.4.4.  Approximating Services: the <service> Element

If the requested service, identified by the service URN (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.) [10] in the <service> element in the request, does not exist for the location indicated, the server can either return an <serviceNotImplemented> (Response Errors) 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 (Service Boundaries by Reference: the <serviceBoundaryReference> Element). 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 (Defining the Service Region with the <serviceBoundary> Element). 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 (Retrieving the Service Boundary via <getServiceBoundary>) request.

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 (Address Validation Exchange) 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 (Overview of Protocol Usage) regarding how this value is to be utilized with a cache. [TBD: This could also be an absolute time.]

7.  Retrieving the Service Boundary via <getServiceBoundary>

As discussed in Section 6.4.5 (Defining the Service Region with the <serviceBoundary> Element), 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 (findService with Service Boundary Reference). 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 (Retrieving the Service Boundary via <getServiceBoundary>). 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>

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>

The <getServiceBoundary> request may also be used to retrieve service boundaries that are expressed as civic addresses, as illustrated in Figure 10 (Civic Address Service Boundary Response).

<?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>

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 (Location Profiles), 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 (Source of Response: <via> Element)) and must contain a <serviceList> element, consisting of a whitespace-separated list of service URNs. The query and response are illustrated in Figure 11 (ListService Query Example).

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>

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 (Two Dimensional Geodetic Profile));

civic:

a profile consisting of civic address location information, described in Section 9.3 (Basic Civic Profile).

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 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> (Response Errors).

These rules enable the use of location profiles not yet specified, while ensuring baseline interoperability. Take, for example, this scenario. Client X has had its firmware upgraded to support the uber-complex-3D location profile. Client X sends location information to Server Y, which does not understand the uber-complex-3D location profile. If Client X also sends location information using the geodetic-2D baseline profile, then Server Y will still be able to understand the request and provide an understandable response, though with location information that might not be as precise or expressive as desired. This is possible because both Client X and Server Y understand the baseline profile. The following transaction, where the XML sent by the client is prepended with 'C:' and the XML sent by the server is prepended with 'S:', demonstrates this:

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">
S:     <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
S:     <p2:exterior>
S:       <p2:LinearRing>
S:         <p2:pos>40.701 -74.020</p2:pos>
S:         <p2:pos>40.876 -73.926</p2:pos>
S:         <p2:pos>40.797 -73.936</p2:pos>
S:         <p2:pos>40.714 -73.984</p2:pos>
S:         <p2:pos>40.701 -74.020</p2:pos>
S:       </p2:LinearRing>
S:     </p2:exterior>
S:     </p2:Polygon>
S:   </serviceBoundary>
S:   <uri>sip:nypd@example.com</uri>
S: </findServiceResponse>

9.2.  Two Dimensional Geodetic Profile

The geodetic-2d location profile is identified by geodetic-2d. Clients use this profile by placing a GML (OpenGIS, “Open Geography Markup Language (GML) Implementation Specification,” January 2003.) [13] <position> element within the <location> element. This is defined by the 'point2D' pattern in the LoST schema (see Section 12 (Relax NG Schema)).

Servers use this profile by placing a GML (OpenGIS, “Open Geography Markup Language (GML) Implementation Specification,” January 2003.) [13] <Polygon> element within the <serviceBoundary> element. This is defined by the 'polygon' pattern in the LoST schema (see Section 12 (Relax NG Schema)).

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] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,” September 2006.), within the <location> element.

Servers use this profile by placing a <civicAddress> element, defined in [11] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,” September 2006.), within the <serviceBoundary> element.

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 (Approximating Services: the <service> Element).

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 (Basic Errors). 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.

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 (Location Profiles).

10.3.  Redirects

LoST defines a pattern for redirect responses. This pattern builds on the basic error pattern (Basic Errors) 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.

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] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) and HTTP-over-TLS [5] (Rescorla, E., “HTTP Over TLS,” May 2000.), 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 (LoST Uniform Resource Locators and Their Resolution).

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 (Non-Normative RELAX NG Schema in XML Syntax).

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" ]
      }?
    }
  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
    }
}

##
##       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 {
  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 }
}

##
##       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 }
  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 =
    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 }*
    }
}

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.

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:

• Application Protocol Tag:

  http

  Defining Publication:

  RFC 2616 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [3]

• Application Protocol Tag:

  https

  Defining Publication:

  RFC 2818 (Rescorla, E., “HTTP Over TLS,” May 2000.) [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] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.) and guidelines in RFC 3023 [6] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.).

MIME media type name:

application

MIME subtype name:

lost+xml

Mandatory parameters:

none

Optional parameters:

charset
Indicates the character encoding of enclosed XML.

Encoding considerations:

Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [6] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.), 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>.

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 (Relax NG Schema). 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>
END

14.5.  Registration Template

This registration template is in accordance with [4] (Petke, R. and I. King, “Registration Procedures for URL Scheme Names,” November 1999.).

URL scheme name:

lost

URL scheme syntax:

See Section 5 (LoST Uniform Resource Locators and Their Resolution)

Character encoding considerations:

See Section 5 (LoST Uniform Resource Locators and Their Resolution)

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 (Security Considerations)

Relevant publications:

This document provides the relevant context for this URL scheme.

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 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.) [2], Standards Action.

geodetic-2d:

Defined in TBD

civic:

Defined in TBD

15.  Security Considerations

There are multiple threats to the overall system of which service 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] (Taylor, T., “Security Threats and Requirements for Emergency Call Marking and Mapping,” July 2006.).

16.  Acknowledgments

[Editor's Note: Names need to be added here. Forgot it...Sorry.]

17.  Open Issues

Please find open issues at: http://www.ietf-ecrit.org:8080/lost/

18.  References

18.1. Normative References

18.2. Informative References

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>
                  <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"/>
          <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>

  </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>

    <define name="serviceBoundary">
      <oneOrMore>
        <element name="serviceBoundary">
          <ref name="locationInformation" />
        </element>
      </oneOrMore>
    </define>
  </div>

  <div>
    <a:documentation>
      Service Boundary Key
    </a:documentation>

    <define name="serviceBoundaryKey">
      <attribute name="key">
        <data type="string">
          <param name="pattern">[a-zA-Z0-9/+=]+</param>
        </data>
      </attribute>
    </define>
  </div>

  <div>
    <a:documentation>
      Via - list of places through which information flowed
    </a:documentation>

    <define name="via">
      <zeroOrMore>
        <element name="via">
          <data type="anyURI"/>
        </element>
      </zeroOrMore>
    </define>
  </div>

  <div>
    <a:documentation>
      Time-to-live pattern
    </a:documentation>

    <define name="timeToLive">
      <attribute name="timeToLive">
        <data type="positiveInteger"/>
      </attribute>
    </define>
  </div>

  <div>
    <a:documentation>
      A QName list
    </a:documentation>

    <define name="qnameList">
      <list>
        <zeroOrMore>
          <data type="QName"/>
        </zeroOrMore>
      </list>
    </define>
  </div>

  <div>
    <a:documentation>
      A location-to-service result.
    </a:documentation>

    <define name="serviceResult">
      <optional>
        <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">
          <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">
        <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"/>
    </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">
        <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>
    <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" />
      </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>

  </div>

</grammar>

Authors' Addresses

Full Copyright Statement

Copyright © 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).