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]