Network Working Group T. Hardie Internet-Draft Qualcomm, Inc. Intended status: Standards Track A. Newton Expires: April 25, 2007 SunRocket H. Schulzrinne Columbia U. H. Tschofenig Siemens October 22, 2006 LoST: A Location-to-Service Translation Protocol draft-ietf-ecrit-lost-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Hardie, et al. Expires April 25, 2007 [Page 1] Internet-Draft LoST October 2006 Abstract This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . ancho 2. Requirements Notation . . . . . . . . . . . . . . . . . . . ancho 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . ancho 4. Overview of Protocol Usage . . . . . . . . . . . . . . . . usage 5. LoST Uniform Resource Locators and Their Resolution . . . . lost- 6. Mapping a Location and Service to URLs: . . . findS 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . ancho 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . ancho 6.2.1. Example Using Geodetic Coordinates . . . . . . . . findS 6.2.2. Civic Address Mapping Example . . . . . . . . . . . findS 6.3. Components of Request . . . . . . . . . . findS 6.3.1. The Element . . . . . . . . . . . . . . locat 6.3.2. The Element . . . . . . . . . . . . . . . servi 6.3.3. Recursion or Redirection . . . . . . . . . . . . . recur 6.3.4. Configuring the Response . . . . . . . . . . . . . inclu 6.4. Components of the Mapping Response . . . . . . . . . . . . . . . . . findS 6.4.1. Source of Response: Element . . . . . . . . via-e 6.4.2. Service URLs: the Element . . . . . . . . . . uri-e 6.4.3. Describing the Service with the Element . . . . . . . . . . . . . . . . . . . . . . displ 6.4.4. Approximating Services: the Element . . servi 6.4.5. Defining the Service Region with the Element . . . . . . . . . . . . . servi 6.4.6. Service Boundaries by Reference: the Element . . . . . . . . servi 6.4.7. The Service Number . . . . . . . . . . . . . . . . servi 6.4.8. Civic Address Validation . . . . . . . . . . . . . valid 6.4.9. Validity: The 'timeToLive' Attribute . . . . . . . timeT 7. Retrieving the Service Boundary via . getSe 8. List Services: . . . . . . . . . . . . . . . listS 9. Location Profiles . . . . . . . . . . . . . . . . . . . . . locat 9.1. Location Profile Usage . . . . . . . . . . . . . . . . locat 9.2. Two Dimensional Geodetic Profile . . . . . . . . . . . geode 9.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . basic 10. Error Handling . . . . . . . . . . . . . . . . . . . . . . error 10.1. Basic Errors . . . . . . . . . . . . . . . . . . . . . basic 10.2. Response Errors . . . . . . . . . . . . . . . . . . . . respo Hardie, et al. Expires April 25, 2007 [Page 2] Internet-Draft LoST October 2006 10.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . redir 11. LoST Transport . . . . . . . . . . . . . . . . . . . . . . trans 12. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . schem 13. Internationalization Considerations . . . . . . . . . . . . ancho 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . iana 14.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . u-nap 14.2. Content-type registration for 'application/lost+xml' . ancho 14.3. LoST Relax NG Schema Registration . . . . . . . . . . . ancho 14.4. LoST Namespace Registration . . . . . . . . . . . . . . ancho 14.5. Registration Template . . . . . . . . . . . . . . . . . ancho 14.6. LoST Location Profile Registry . . . . . . . . . . . . profi 15. Security Considerations . . . . . . . . . . . . . . . . . . secur 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . ancho 17. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . ancho 18. References . . . . . . . . . . . . . . . . . . . . . . . . ancho 18.1. Normative References . . . . . . . . . . . . . . . . . ancho 18.2. Informative References . . . . . . . . . . . . . . . . ancho Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . schem Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 0 Intellectual Property and Copyright Statements . . . . . . . . Hardie, et al. Expires April 25, 2007 [Page 3] Internet-Draft LoST October 2006 1. Introduction This document describes a protocol for mapping a service identifier [10] and location information compatible with PIDF-LO [8] to one or more service contact URIs. Example contact URI schemes include sip [14], xmpp [15], and tel [16]. While the initial focus is on providing mapping functions for emergency services, it is likely that the protocol is applicable to any service URN. For example, in the United States, the "2-1-1" and "3-1-1" services follow a similar location-to-service behavior as emergency services. This document names this protocol "LoST", for Location-to-Service Translation. LoST Satisfies the requirements [18] for mapping protocols. LoST provides a number of operations, centered around mapping locations and service URNs to URIs and associated information. LoST mapping queries can contain either civic or geodetic location information. For civic addresses, LoST can indicate which parts of the civic address are known to be valid or invalid, thus providing address validation. LoST indicates errors in the location data to facilitate debugging and proper user feedback, but also provides best-effort answers. LoST queries can be resolved recursively or iteratively. To minimize round trips, LoST caches individual mappings and indicates the region for which the same answer would be returned ("service region"). As currently defined, LoST messages are carried in HTTP and HTTPS protocol exchanges, facilitating use of TLS for protecting the integrity and confidentiality of requests and responses. This document focuses on the description of the protocol between the mapping client (seeker or resolver) and the mapping server (resolver or other servers). The relationship between other functions, such as discovery of mapping servers, data replication and the overall mapping server architecture are described in a separate document [19]. The query message carries location information and a service identifier encoded as a Uniform Resource Name (URN) (see [10]) from the LoST client to the LoST server. The LoST server uses its database to map the input values to one or more Uniform Resource Identifiers (URI) and returns those URIs along with optional information such as hints about the service boundary in a response message to the LoST client. If the server cannot resolve the query itself, it may in turn query another server or return the address of