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