ECRIT WG James Polk Internet-Draft Cisco Systems Expires: January 6, 2010 July 6, 2009 Intended Status: Standards Track (PS) Updates: RFC 5222 (if published) Geocoding and Reverse-geocoding Using Location-to-Service Translation draft-polk-ecrit-lost-geocoding-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 6, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document creates new service URNs for geocoding and reverse geocoding location formats to be used by location-to-service translation protocol (LoST) to convert location values into a format of choice. Polk Expires January 6, 2010 [Page 1] Internet-Draft Geocoding using LoST July 2009 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 RFC 2119 [RFC 2119]. 1. Introduction Many devices are starting to use location in one of many formats, but not always the same format. The most common of these formats is civic location (defined by RFC 4119 & 4776) and geodetic (coordinate) location (like GPS). Various arguments have been made to have all devices choose one format - and move forward with that. This is like choosing one signaling protocol for voice or file transfer. These two will remain to have multiple choices for years (decades?) to come. Location formats probably is no different. In the interim, i.e., before one format is chosen to solve everything, there needs to be translation between the many formats. End devices should not necessarily be burdened with making this conversion, but can correctly identify which format they have or have just received, and request that this format be converted to the one that end device prefers. This preference can be for many reasons, but is more likely because an application running on that end device prefers location in a certain format, for whatever reason. This document specifies how LoST (Location-to-Service Translation Protocol) [RFC5222] can be used to accomplish this conversion. The service is converting coordinate location to civic addressing, called geocoding, and converting civic addressing to geodetic location, called reverse-geocoding. LoST is primarily used by communicating two specific pieces of information and having a URI be returned. The two pieces of information are #1 - a location (similar to the PIDF-LO format [RFC4119]), and #2 - what service is to be attained that services that location. The service is identified by the requester by a URN. The LoST server then determines which URI is appropriate for that service within that location. LoST servers need to accept locations in both the civic and geodetic formats, thus LoST servers are logical to convert one location format to another. This document specifies how a location plus a service identifier wishes to receive back a converted location, and not a URI to be contacted. To accomplish this service, a new service URN has to be created for each type of conversion. The end device performs a LoST request Polk Expires January 6, 2010 [Page 2] Internet-Draft Geocoding using LoST July 2009 with its non-preferred location format it possesses, with the URN of the type of conversion it wants, and the response will contain the converted location. 2. Geocoding URNs This document creates and registers the following URNs for the geocoding service: urn:service:geocoding and urn:service:rev-geocoding This is to be placed in the <> element of a LoST request. 3. Registration of Template TBD (and will follow the rules according to RFC 3406 [RFC3406]) 4. Examples of LoST Request and Response TBD (will show a LoST query containing geodetic location and geocode service URN, and return a civic location) 5. Security considerations This document introduces no additional security considerations from that in RFC 5222, the LoST specification, or in RFC 5031, the URN Services specification. 6. IANA considerations TBD 7. Acknowledgments Your name here... or if you contribute a fair amount of text, you can be a co-author. Polk Expires January 6, 2010 [Page 3] Internet-Draft Geocoding using LoST July 2009 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC5222] T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008 [RFC3406] L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", RFC 3406, October 2002 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", RFC 4776, November 2006 [RFC5031] H. Schulzrinne, "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008 8.2. Informative References [] Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Polk Expires January 6, 2010 [Page 4]