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

Differences from draft-polk-ecrit-lost-transformations-urn-00.txt

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]