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

ECRIT WG                                                     James Polk
Internet-Draft                                            Cisco Systems
Expires: April 19, 2010                                October 19, 2009
Intended Status: Standards Track (PS)                           
Updates: RFC 5222 (if published)

             The Transformations Uniform Resource Name (URN) 
                 Using Location-to-Service Translation
              draft-polk-ecrit-lost-transformations-urn-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 April 19, 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 a new top level service URN for 
   transformations to be used by location-to-service translation 
   protocol (LoST) to convert similar values into a different format of
   choice.  Within this 'transformations' URN, there are two 
   sub-elements specifically created for geocoding and reverse 
   geocoding location formats by this document.

Polk                   Expires April 19, 2010                  [Page 1]
Internet-Draft          LoST Transformations                   Oct 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 April 19, 2010                  [Page 2]
Internet-Draft          LoST Transformations                   Oct 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. Transformations URN

   This document creates a URN for transformations, as shown here:

      urn:service:transformations

   This URN is for converting a dissimilar values meaning the same 
   thing into another format.  For example, transforming civic location
   format value into a coordinate pair location format value (see 
   Section 2.1 for more on geocoding).


2.1 Geocoding URNs

   This document creates and registers the following sub-element URNs 
   below the top-level 'transformations' URN for a geocoding service:

      urn:service:transformations:geocoding

   and

      urn:service:transformations:rev-geocoding

   This is to be placed in the <> element of a LoST request.


3.  One Transaction Verses Two

   Strictly speaking, LoST is about including a URN of a service, and 
   the location of the requester in a request message, and getting a 
   response message that includes the URI of who the original requester
   needs to contact for that service.  In some cases, for 
   transformations, a LoST server can possess both versions of the same
   information. This is most true for location information in two 
   different formats.  If a user wants to convert, or transform one 
   location format to another, it can ask a LoST server if it can 
   convert one location format to another.  If the LoST server cannot, 
   or is unwilling to, the LoST reply will include only the URI of the 
   server to be connected for this conversion.

   With this as a background, here are two possibilities for a LoST 
   query for location transformation:  

   Option #1 - For LoST servers that have the transformation 
               information local to it, or otherwise chooses to have a 
               single LoST transaction fulfill the transformation 
               request, the response can have the transformation in the


Polk                   Expires April 19, 2010                  [Page 3]
Internet-Draft          LoST Transformations                   Oct 2009

               response.  

   Option #2 - For time in which a LoST server does not have the 
               transformation information local (or decides it does not
               want to go fetch the information requested for a single 
               LoST transaction with the requester), or otherwise does 
               not want to provide this transformation information in a
               single transaction - the LoST server can merely provide 
               a URI of the server that can answer this transformation 
               query in the LoST response.


4.  Registration of Template

   TBD (and will follow the rules according to RFC 3406 [RFC3406])


5.  Examples of LoST Request and Response

   TBD

   (will show a LoST query containing geodetic location and geocode 
   service URN, and return a civic location)



6.  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.


7.  IANA considerations

   TBD


8.  Acknowledgments

   The author would like to thank Brian Rosen, Richard Barnes, Andy 
   Newton and Hannes Tschofenig for the useful comments.


9.  References

9.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: 


Polk                   Expires April 19, 2010                  [Page 4]
Internet-Draft          LoST Transformations                   Oct 2009

           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


9.2.  Informative References

 []


Authors' Addresses

   James Polk
   3913 Treemont Circle
   Colleyville, Texas, USA
   +1.817.271.3552

   mailto: jmpolk@cisco.com























Polk                   Expires April 19, 2010                  [Page 5]