Network Working Group                                           A. Forte
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track                     Columbia University
Expires: September 20, 2008                               March 19, 2008


       Location-to-Service Translation Protocol (LoST) Extensions
                draft-forte-ecrit-lost-extensions-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 20, 2008.

Abstract

   An important class of location-based services answer the question
   "What instances of this service are closest to me?"  Examples include
   finding restaurants, gas stations, stores, automated teller machines,
   wireless access points (hot spots) or parking spaces.  Currently, the
   Location-to-Service Translation (LoST) protocol only supports mapping
   locations to a single service based on service regions.  This
   document describes an extension that allows queries "N nearest" and
   "within distance X".







Forte & Schulzrinne    Expires September 20, 2008               [Page 1]

Internet-Draft               LoST Extensions                  March 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   3.  Service Region . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  New Query Types: "N nearest" and "within distance X" . . . . .  4
   5.  LoST Extensions  . . . . . . . . . . . . . . . . . . . . . . .  4
     5.1.  New Use of Circular Shape in Queries . . . . . . . . . . .  4
     5.2.  Limiting the Number of Returned Service URIs . . . . . . .  5
     5.3.  The <serviceLocation> Element in Responses . . . . . . . .  6
   6.  Distance Calculation: General Considerations . . . . . . . . .  9
   7.  Complex Queries  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11


































Forte & Schulzrinne    Expires September 20, 2008               [Page 2]

Internet-Draft               LoST Extensions                  March 2008


1.  Introduction

   The Location-to-Service Translation (LoST) protocol [LOST] maps
   service identifiers (URNs) and civic or geospatial information to
   service URIs, based on service regions.  While motivated by mapping
   locations to the public safety answering point (PSAP) serving that
   location, the protocol has been designed to generalize to other
   location mapping services.

   However, the current LoST query model assumes that each service URI
   has a service region and that service regions do not overlap.  This
   fits the emergency services model, where the service region of a PSAP
   is given by jurisdictional boundaries, but does not work as well for
   other services that do not have clearly defined boundaries.  For
   example, any given location is likely served by a number of different
   restaurants, depending on how far the prospective customer is willing
   to walk or drive.

   We extend LoST with two additional queries, giving the protocol the
   ability to find the N nearest instances of a particular service and
   all services within a given radius.


2.  Requirements notation

   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 [RFC2119].


3.  Service Region

   In the LoST protocol, the <findServiceResponse> message includes a
   service region [LOST].  This is the geographical area for which a
   query will always receive the same response.  Because of this, the
   LoST client will issue a new query only when it has moved out of its
   current service region.

   In emergency services, as soon as the service region changes, the
   client queries the LoST server in order to discover the new PSAP.
   This is important since clients need to know their PSAP before an
   emergency occurs, so that no time is wasted in discovering the
   correct PSAP during the emergency.

   Other location-based services are not as critical as emergency
   services, and points of interest can be discovered on demand, at the
   time they are needed and not before.  Because of this, for location-
   based services other than emergency services, service regions will be



Forte & Schulzrinne    Expires September 20, 2008               [Page 3]

Internet-Draft               LoST Extensions                  March 2008


   of little or no use.


4.  New Query Types: "N nearest" and "within distance X"

   The two new types of queries we introduce are "N nearest" and "within
   distance X".  The former returns the N points of interest closest to
   the client's physical location, the latter discovers all those points
   of interest residing within a given distance from the client's
   physical location.


5.  LoST Extensions

   For queries "within distance X", the LoST client needs to specify to
   the server the range within which instances of a particular service
   should be searched.  In order to do this, we make use of the circular
   shape [PIDF-LO] in LoST queries.

   For queries "N nearest", the lost client needs to let the server know
   N, that is, the maximum number of service URIs to be returned in a
   response.  In order to specify this, we introduce a new attribute for
   the <findService> element.

   We introduce a new element in LoST responses, namely
   <serviceLocation>.  This new element is used by the server to
   indicate to the client the physical location of points of interest.
   In doing so, the client can compute the distance and other metrics
   between its current location and the points of interest.

5.1.  New Use of Circular Shape in Queries

   In [PIDF-LO] different shapes are defined in order to represent a
   point and an area of uncertainty within which the user might be
   situated.  In order to extend LoST to support "N nearest" and "within
   distance X" queries, we use the PIDF-LO circular shape [PIDF-LO].  In
   the present context, rather than seeing the circle as an area of
   uncertainty for the physical location of the client, we see it as the
   area within which we want to find a service.

   Figure 1 shows a <findService> geodetic query using the circular
   shape.  In particular, with the query shown in Figure 1, we are
   asking the LoST server to send us a list of service URNs for pizza
   places within 850.24 meters from our approximate position specified
   in <p2:pos>.






Forte & Schulzrinne    Expires September 20, 2008               [Page 4]

Internet-Draft               LoST Extensions                  March 2008


   <?xml version="1.0" encoding="UTF-8"?>
   <findService
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"
     serviceBoundary="value"
     recursive="true">
     <location id="6020688f1ce1896d" profile="geodetic-2d">
       <p2:Circle srsName="urn:ogc:def:crs:EPSG::4326">
         <p2:pos>37.775 -122.422</p2:pos>
         <p2:radius uom="urn:ogc:def:uom:EPSG::9001">
            850.24
         </p2:radius>
       </p2:Circle>
     </location>
     <service>urn:service:local.pizza</service>
   </findService>


   Figure 1: A <findService> geodetic query using the circle shape

5.2.  Limiting the Number of Returned Service URIs

   Limiting the number of results is helpful, particularly for mobile
   devices with limited bandwidth.  For "N closest" queries, the client
   needs to be able to tell the server to return no more than N service
   URIs.  In order to specify such limit, we introduce a new attribute,
   namely 'limit', to the <findService> element.  Figure 2 shows a
   <findService> geodetic query where the client asks the server to
   return no more than 20 service URIs.  When receiving such query, the
   LoST server will return a list of no more than 20 points of interest.

   If the available points of interest are more than N, then the server
   has to identify the N points of interest closest to the client's
   physical location and include those in the response.

















Forte & Schulzrinne    Expires September 20, 2008               [Page 5]

Internet-Draft               LoST Extensions                  March 2008


   <?xml version="1.0" encoding="UTF-8"?>
   <findService
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"
     serviceBoundary="value"
     recursive="true"
     limit="20">
     <location id="6020688f1ce1896d" profile="geodetic-2d">
       <p2:Circle srsName="urn:ogc:def:crs:EPSG::4326">
         <p2:pos>37.775 -122.422</p2:pos>
         <p2:radius uom="urn:ogc:def:uom:EPSG::9001">
            850.24
         </p2:radius>
       </p2:Circle>
     </location>
     <service>urn:service:local.pizza</service>
   </findService>


   Figure 2: A <findService> geodetic query with the new 'limit'
   attribute

5.3.  The <serviceLocation> Element in Responses

   It is important for the LoST client to know the location of a point
   of interest so that distance, route and other metrics can be
   computed.  We introduce a new element, namely <serviceLocation>.  The
   <serviceLocation> element contains the geodetic coordinates of a
   point of service and MUST be contained in a <mapping> element.  In
   responses such as <findServiceResponse> [LOST], a list of service
   URIs, each with its own <serviceLocation> element, MUST be returned.
   The order of service URIs in the list is not relevant.

   The <serviceLocation> element has one single attribute, 'profile', in
   order to specify the profile used.  Only geodetic profiles MUST be
   used since, if needed, the client can compute the civic location from
   geodetic coordinates.  Furthermore, the position specified in
   <serviceLocation> MUST be represented by using the <Point> element.
   The <Point> element is described in Section 12.2 of [LOST] and in
   Section 5.2.1 of [PIDF-LO].  Figure 3 shows a <findServiceResponse>
   answer containing two location-to-service-URI mappings.

   It is important to notice that since service regions are not relevant
   in the present context, they are not present in the response.  Also,
   as mentioned earlier, the <serviceLocation> element uses only
   geodetic coordinates.  A consequence of this is that the format of
   the response message is the same for both geodetic coordinates and
   civic address types of queries.



Forte & Schulzrinne    Expires September 20, 2008               [Page 6]

Internet-Draft               LoST Extensions                  March 2008


   NOTE: The <locationUsed> element cannot be extended for this purpose
   as it is defined outside of the <mapping> element.  In particular, in
   a response the <locationUsed> element is always one, while the number
   of service URIs is typically more than one.















































Forte & Schulzrinne    Expires September 20, 2008               [Page 7]

Internet-Draft               LoST Extensions                  March 2008


      <?xml version="1.0" encoding="UTF-8"?>
      <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
        xmlns:p2="http://www.opengis.net/gml">
        <mapping
          expires="2007-01-01T01:44:33Z"
          lastUpdated="2006-11-01T01:00:00Z"
          source="authoritative.example"
          sourceId="7e3f40b098c711dbb6060800200c9a66">
          <displayName xml:lang="it">
            Che bella pizza e all' anima da' pizza da Toto'
          </displayName>
          <service>urn:service:local.pizza</service>
          <uri>sip:chebella@example.com</uri>
          <uri>xmpp:chebella@example.com</uri>
          <serviceNumber>2129397040</serviceNumber>
          <serviceLocation profile="geodetic-2d">
            <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
              <p2:pos>33.665 -112.432</p2:pos>
            </p2:Point>
          </serviceLocation>
        </mapping>
        <mapping
          expires="2007-01-01T01:44:33Z"
          lastUpdated="2006-11-01T01:00:00Z"
          source="authoritative.example"
          sourceId="7e3f40b098c711dbb6060800200c9b356">
          <displayName xml:lang="en">
            King Mario's Pizza
          </displayName>
          <service>urn:service:local.pizza</service>
          <uri>sip:marios@example.com</uri>
          <uri>xmpp:marios@example.com</uri>
          <serviceNumber>2129397157</serviceNumber>
          <serviceLocation profile="geodetic-2d">
            <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
              <p2:pos>33.683 -112.412</p2:pos>
            </p2:Point>
          </serviceLocation>
        </mapping>
        <path>
          <via source="resolver.example"/>
          <via source="authoritative.example"/>
        </path>
        <locationUsed id="6020688f1ce1896d"/>
      </findServiceResponse>


   Figure 3: A <findServiceResponse> answer



Forte & Schulzrinne    Expires September 20, 2008               [Page 8]

Internet-Draft               LoST Extensions                  March 2008


6.  Distance Calculation: General Considerations

   In order to find the closest point of interest to the client's
   physical location, the LoST server needs to compute the distance
   between the client's location and the location of all available
   points of interest.  How to compute such distance is out of the scope
   of this document.  We can say, however, that while with geodetic
   coordinates such computation is straightforward, when using civic
   location, geo-coding would be required previous to the computation of
   the distance.

   Distance between client and point of interest might not always be a
   good metric.  For example, two points can be close in terms of
   distance but there could be an obstacle such as a river in between
   them.  Because of this, computing a route rather than just straight-
   line distance, might represent a more accurate way to solve the
   problem.  Route computation does not have to happen on the server
   side but rather, could be performed on the LoST client itself, after
   receiving the list of service URIs.


7.  Complex Queries

   Often, people select services not just based on proximity, but also
   on a range of other criteria, such as their reputation, the expected
   price range, hours of operation or whether the service is accepting
   service requests.  While it would be possible to extend the LoST
   response to incorporate additional information, such information is
   likely to be highly service-dependent, may change frequently and may
   well be offered by multiple third parties.  For example, there are
   multiple services that rate restaurants.  The availability of seats
   in restaurants may change hour by hour.  Thus, we discourage attempts
   to extend the LoST response to include such information.  Instead,
   clients should query the service URIs returned to obtain such
   information, either as a human-readable web page or as a standardized
   service-specific data format, e.g., as a microformat.


8.  Security Considerations

   The same security considerations as in [LOST] apply.


9.  IANA Considerations

   TODO





Forte & Schulzrinne    Expires September 20, 2008               [Page 9]

Internet-Draft               LoST Extensions                  March 2008


10.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [LOST]     Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol, IETF Internet Draft (Work in Progress)",
              February 2008.

   [PIDF-LO]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              PIDF-LO Usage Clarification, Considerations and
              Recommendations. IETF Internet Draft (Work in Progress)",
              February 2008.


Authors' Addresses

   Andrea G. Forte
   Columbia University
   Department of Computer Science
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027
   USA

   Email: andreaf@cs.columbia.edu


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027
   USA

   Email: hgs@cs.columbia.edu















Forte & Schulzrinne    Expires September 20, 2008              [Page 10]

Internet-Draft               LoST Extensions                  March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Forte & Schulzrinne    Expires September 20, 2008              [Page 11]