ECRIT WG James Polk Internet-Draft Cisco Systems Expires: Sept 8, 2010 March 8, 2010 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-01 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. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 September 8, 2010. Polk Expires Sept 8, 2010 [Page 1] Internet-Draft LoST Transformations Mar 2010 Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. 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 This document creates a URN for transformations to be used by LoST (Location-to-Service Translation Protocol) [RFC5222]. Today, the most obvious transformation using LoST is from one location format to another. Within each LoST request, there is a location provided, along with a service URN the LoST server uses to determine which URI to give in the LoST response, based on the location of the requester. Fundamentally, LoST handles most locations - most likely in both the geodetic and civic formats [RFC4119]. It seems only logical to ask the LoST server, who likely has both location formats loaded, to transform one location format to the other format. Transforming a geodetic coordinate pair to a civic location address is called geocoding. The reverse, transforming a civic address into a geodetic coordinate pair is called reverse-geocoding. If a LoST server does not have both formats present for this transformation, but knows of a remote server to contact for such an operation, the LoST server returns the URI of that remote server in the LoST response, leaving it to the host to request this conversion of formats. This latter operation will likely not be done using LoST, but rather a protocol such as HTTP(S). This document does not specify how this latter transaction occurs. 2. 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 Polk Expires Sept 8, 2010 [Page 2] Internet-Draft LoST Transformations Mar 2010 transformations, a LoST server can possess multiple formats 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 for who to contact to make this conversion or transformation. On the other hand, and within the same LoST request (implicit or explicit), if the LoST server has both formats of the same location - it should be able to respond with the transformation. This increases the user/device experience and makes everything more efficient by reducing the number of transactions to get the information to the asking party. If the LoST server cannot perform this transformation, or is unwilling to, the LoST response should include only the URI of the server to be connected for this transformation. 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 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. This document leaves it up to the implementation to decide which way it wants to go - of the 2 choices above. If a transformation cannot be performed by the LoST server, the response SHOULD contain the URI of where to contact that can do this service, or provide an error indicating it cannot. 3. Transformations URN This document creates the service URN for transformations to be used by the LoST protocol, as shown here: urn:service:transformations This URN is for converting a dissimilar values meaning the same thing into another format, perhaps to a specified format, based on the LoST request. For example, transforming civic location format Polk Expires Sept 8, 2010 [Page 3] Internet-Draft LoST Transformations Mar 2010 value into a coordinate pair location format value. 3.1 Sub-Services for the 'transformation' Service This section defines the transformation service using the top-level service label 'transformation'. urn:service:transformation urn:service:transformation.geocoding urn:service:transformation.reverse-geocoding Other transformations can be added to this document as it progresses. 4. An Example Transformation [section under construction] [Editor's Note: this will show a LoST request, along with 2 LoST responses - one showing the transformation in the LoST response, the other showing the URI to be contacted for the transformation.] 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 6.1. Sub-Services for the 'transformation' Service This section defines the service registration within the IANA registry, using the top-level service label 'transformation'. urn:service:transformation 'transformation' service denotes a top-level service, and it encompasses all of the services listed below. urn:service:transformation.geocoding This service identifier is used to indicate a conversion from a geodetic coordinate-pair location format to a civic location format is desired. urn:service:transformation.reverse-geocoding This service identifier is used to indicate a conversion from a civic location format to a geodetic coordinate-pair location format is desired. Polk Expires Sept 8, 2010 [Page 4] Internet-Draft LoST Transformations Mar 2010 6.2. Initial IANA Registration The following table contains the initial IANA registration for transformation services. Service Reference Description ------------------------------------------------------- urn:service:transformation [this doc] Transformation services urn:service:transformation.geocoding [this doc] geocoding transformation urn:service:transformation.reverse-geocoding [this doc] reverse-geocoding transformation 7. Acknowledgments The author would like to thank Brian Rosen, Richard Barnes, Andy Newton and Hannes Tschofenig for the useful comments. 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 [none] Polk Expires Sept 8, 2010 [Page 5] Internet-Draft LoST Transformations Mar 2010 Authors' Addresses James Polk 3913 Treemont Circle Colleyville, Texas, USA +1.817.271.3552 mailto: jmpolk@cisco.com Polk Expires Sept 8, 2010 [Page 6]