Network Working Group                                          T. Hardie
Internet-Draft                                            Qualcomm, Inc.
Expires: August 30, 2006                                       A. Newton
                                                          Verisign, Inc.
                                                          H. Schulzrinne
                                                             Columbia U.
                                                           H. Tschofenig
                                                       February 26, 2006

            LoST: A Location-to-Service Translation Protocol

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 30, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This document describes an XML-based protocol for mapping service
   identifiers and geospatial or civic location information to service
   contact URIs.  In particular, it can be used to determine the

Hardie, et al.           Expires August 30, 2006                [Page 1]

Internet-Draft                    LoST                     February 2006

   location-appropriate PSAP for emergency services.

Table of Contents

   1.   Requirements notation  . . . . . . . . . . . . . . . . . . .   3
   2.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.   Server Discovery . . . . . . . . . . . . . . . . . . . . . .   7
   5.   Service Types  . . . . . . . . . . . . . . . . . . . . . . .   8
   6.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   7.   Deployment Methods . . . . . . . . . . . . . . . . . . . . .  11
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  13
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  14
   10.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .  15
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1   Normative References . . . . . . . . . . . . . . . . . .  16
     11.2   Informative References . . . . . . . . . . . . . . . . .  16
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
        Intellectual Property and Copyright Statements . . . . . . .  18

Hardie, et al.           Expires August 30, 2006                [Page 2]

Internet-Draft                    LoST                     February 2006

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [3].

Hardie, et al.           Expires August 30, 2006                [Page 3]

Internet-Draft                    LoST                     February 2006

2.  Introduction

   This document describes a protocol for mapping a service identifier
   and location information compatible with PIDF-LO [9] to one or more
   service contact URIs.  These URIs may have any reasonable scheme,
   including sip, xmpp, and tel.  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 usage "LoST" for Location-to-
   Service Translation Protocol.  The features of LoST are:

   o  Supports queries using civic as well as geospatial location

   o  Can be used in both recursive and iterative resolution.

   o  Can be used for civic address validation.

   o  A hierarchical deployment of mapping servers is independent of
      civic location labels.

   o  Can indicate errors in the location data to facilitate debugging
      and proper user feedback while simultaneously providing best-
      effort answers.

   o  Mapping can be based on either civic or geospatial location
      information, with no performance penalty for either.

   o  Service regions can overlap.

   o  Satisfies the requirements [5] for mapping protocols.

   o  Minimizes round trips by caching individual mappings as well as
      coverage regions ("hinting").  Unless otherwise desired, there is
      only one message exchange (roundtrip delay) between the client
      requesting a mapping and the designated resolver.  This also
      facilitates reuse of TLS or other secure transport association
      across multiple queries.

   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 in general, will be described in a
   separate document. [10] is a first attempt to describe such a mapping

Hardie, et al.           Expires August 30, 2006                [Page 4]

Internet-Draft                    LoST                     February 2006

   server architecture.

Hardie, et al.           Expires August 30, 2006                [Page 5]

Internet-Draft                    LoST                     February 2006

3.  Usage

   The client queries a server, indicating the desired service and the
   location object.  If the query succeeds, the server returns a result
   that includes one or more URIs for reaching the appropriate service
   for the location indicated.  Depending on the query, the result may
   contain a region where the same mapping would apply, a reference to
   another server to which the client should send a query, and error
   messages indicating problems with interpretation of location
   information.  The combination of these components are left to the
   needs and policy of the jurisdiction where the server is being

   The interaction between the client and server is triggered by four
   types of events:

   1.  When the client starts up and/or attaches to a new network

   2.  When the client detects that its location has changed
       sufficiently that it is outside the bounds of the region returned
       in an earlier query.

   3.  When cached mapping information has expired.

   4.  When calling for a particular service.  During such calls, a
       client MAY request a short response that contains only the
       mapping data, omitting region information.  The use of a
       different transport protocol is TBD.

   Cached answers are expected to be used by clients only after failing
   to accomplish a location-to-URI mapping at call time.  Cache entries
   may expire according to their time-to-live value, or they may become
   invalid if the location of the caller's device moves outside the
   boundary limits of the cache entry.  Boundaries for cache entries may
   be set in both geospatial and civic terms.

Hardie, et al.           Expires August 30, 2006                [Page 6]

Internet-Draft                    LoST                     February 2006

4.  Server Discovery

   There are likely to be a variety of ways that clients can discover
   appropriate LoST servers, including DHCP, SIP device configuration,
   or DNS records for their signaling protocol domain, e.g., the AOR
   domain for SIP.  The appropriate server depends on, among other
   considerations, who operates LoST services, including the Internet
   Service Provider (ISP), Voice Service Provider (VSP), or the user's
   home domain.  In each case, the host name returned may be resolved
   using DDDS methods.  [Details TBD.]

Hardie, et al.           Expires August 30, 2006                [Page 7]

Internet-Draft                    LoST                     February 2006

5.  Service Types

   The type of service desired is specified by the <service> element.
   The emergency identifiers listed in the registry established with [6]
   will be used in this document.

   If a more specific service is requested but does not exist,
   information for the more generic service SHOULD be returned.  For
   example, a request for might return
   urn:service:sos in the United States since citizens in that country
   reach the fire department through the common emergency service.

Hardie, et al.           Expires August 30, 2006                [Page 8]

Internet-Draft                    LoST                     February 2006

6.  Example

   After performing link layer attachment and end host performs stateful
   address autoconfiguration (in our example) using DHCP.  DHCP provides
   the end host with civic location information (encoded in UTF-8

      | CAtype | CAvalue       |
      | 0      | US            |
      | 1      | New York      |
      | 3      | New York      |
      | 6      | Broadway      |
      | 22     | Suite 75      |
      | 24     | 10027-0401    |

                 Figure 1: DHCP Civic Information Example

   Additionally, DHCP provides information about the LoST server that
   can be contacted.  An additional step of indirection is possible, for
   example by having DHCP return a domain name that has to be resolved
   to one or more IP addresses hosting LoST servers.

   Both at attachment time and call time, the client places a LoST
   request, including its civic location and the desired service.  A
   snippet of the request that omits encapsulating protocol information
   and namespace declarations is shown below:

             <cl:A1>New York</cl:A1>
             <cl:A3>New York</cl:A3>
             <cl:LOC>Suite 75</cl:LOC>

Hardie, et al.           Expires August 30, 2006                [Page 9]

Internet-Draft                    LoST                     February 2006

   Since the contacted LoST server has the requested information
   available the following response is returned.  The response
   indicates, as a human readable display string that the 'New York City
   Police Department' is responsible for the given geographical area.
   The indicated URI allows the user to start communication using SIP or
   XMPP.  The 'civicMatch' elements indicates which parts of the civic
   address were matched successfully.  Other parts of the address, here,
   the suite number, were ignored and not validated.  The region part of
   the response indicates that all of New York City would result in the
   same response.  The dialstring element indicates that the service can
   be reached via the dial string 9-1-1.  A snippet of the response is
   shown below, omitting namespace details and protocol wrappers:

       <response expires="2006-03-09T01:53:33.396Z">
         <displayName>New York City Police Department</displayName>
               <cl:A1>New York</cl:A1>
               <cl:A3>New York</cl:A3>
               <cl:A1>New York</cl:A1>
               <cl:A3>New York</cl:A3>

Hardie, et al.           Expires August 30, 2006               [Page 10]

Internet-Draft                    LoST                     February 2006

7.  Deployment Methods

   Because services for emergency contact resolution may differ
   depending on local or service needs, this document only specifies the
   "wire format" for LoST services and explicitly leaves open the
   possibility for many different types of deployment.

   For instance:

      During discovery, a client may be directed to issue all queries to
      an LoST service completely authoritative for a given jursidiction.

      A client may be directed to issue queries to an LoST server that
      acts as a reflector.  In such a case, the LoST server analyzes the
      query to determine the best server to wich to refer the client.

      Or the client may be directed to a server that performs further
      resolution on behalf of the client.

   A LoST service may also be represented by multiple LoST servers,
   either grouped together or at multiple network locations.  Using
   S-NAPTR [11], clients may be given a list of multiple servers to
   which queries can be sent for a single service.

   For instance, the service at may advertise LoST
   service at,, and  Each
   server may given a different preference.  In this case, 'local1' and
   'local2' may be given a lower preference (more preferred) than
   'master', which might be a busier server or located further away.

   +-----------+             pref 10 +-----------+
   |           |-------------------->+           |
   |  client   |------               |  local1   |
   |           |---   \              |           |
   +-----------+   \   \             +-----------+
                    \   \
                     \   \           +-----------+
                      \   \  pref 10 |           |
                       \   --------->|  local2   |
                        \            |           |
                         \           +-----------+
                           \                           +-----------+
                            \                  pref 20 |           |
                             ------------------------->|  master   |
                                                       |           |

Hardie, et al.           Expires August 30, 2006               [Page 11]

Internet-Draft                    LoST                     February 2006


Hardie, et al.           Expires August 30, 2006               [Page 12]

Internet-Draft                    LoST                     February 2006

8.  IANA Considerations

   TBD, such as namespace registrations.

Hardie, et al.           Expires August 30, 2006               [Page 13]

Internet-Draft                    LoST                     February 2006

9.  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, LoST
   RECOMMENDS the use of channel security, such as TLS.

   A more detailed description of threats and security requirements are
   provided in [4].

   [Editor's Note: A future version of this document will describe the
   countermeasures based on the security requirements outlined in [4].]

Hardie, et al.           Expires August 30, 2006               [Page 14]

Internet-Draft                    LoST                     February 2006

10.  Open Issues

   A number of open issues have been identified that are not yet
   addressed by this draft version:

   o  The transport mechanism, such as "plain" HTTP or SOAP.

   o  The appropriate transport protocols beyond TLS/TCP, such as
      whether UDP is to be supported.

   o  LoST service operators may determine which transfer protocol most
      meets their needs, and advertise their availability using the DNS
      DDDS application S-NAPTR [11].  The aspect of service discovery
      and load balancing needs to be described.

   o  Error conditions and codes.

   o  The inclusion of dial string information.

   o  The name 'LoST' is a placeholder before a better name is found.

   o  An internationalization considerations section is needed.

   o  The XML schema's are not yet provided.

   o  Full-fletched examples are missing.

   o  The security consideration section is incomplete.

   o  The IANA consideration section is missing.

Hardie, et al.           Expires August 30, 2006               [Page 15]

Internet-Draft                    LoST                     February 2006

11.  References

11.1  Normative References

   [1]  World Wide Web Consortium, "XML Schema Part 2: Datatypes",
        W3C XML Schema, October 2000,

   [2]  World Wide Web Consortium, "XML Schema Part 1: Structures",
        W3C XML Schema, October 2000,

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

   [4]  Schulzrinne, H., "Security Threats and Requirements for
        Emergency Calling", draft-taylor-ecrit-security-threats-01 (work
        in progress), December 2005.

   [5]  Schulzrinne, H. and R. Marshall, "Requirements for Emergency
        Context Resolution with Internet Technologies",
        draft-ietf-ecrit-requirements-03 (work in progress),
        February 2006.

   [6]  Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
        draft-schulzrinne-sipping-service-01 (work in progress),
        October 2005.

   [7]  Mealling, M., "The IETF XML Registry",
        draft-mealling-iana-xmlns-registry-03 (work in progress),
        November 2001.

   [8]  OpenGIS, "Open Geography Markup Language (GML) Implementation
        Specification", OGC OGC 02-023r4, January 2003.

   [9]  Peterson, J., "A Presence-based GEOPRIV Location Object Format",
        RFC 4119, December 2005.

11.2  Informative References

   [10]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
         Framework", draft-schulzrinne-ecrit-mapping-arch-00 (work in
         progress), October 2005.

   [11]  Daigle, L. and A. Newton, "Domain-Based Application Service
         Location Using SRV RRs and the Dynamic Delegation Discovery
         Service (DDDS)", RFC 3958, January 2005.

Hardie, et al.           Expires August 30, 2006               [Page 16]

Internet-Draft                    LoST                     February 2006

Authors' Addresses

   Ted Hardie
   Qualcomm, Inc.

   Andrew Newton
   Verisign, Inc.

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027

   Phone: +1 212 939 7004

   Hannes Tschofenig
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739


Hardie, et al.           Expires August 30, 2006               [Page 17]

Internet-Draft                    LoST                     February 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hardie, et al.           Expires August 30, 2006               [Page 18]