One document matched: draft-polk-ecrit-lost-geocoding-00.txt

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]