[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                           A. Forte
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track                     Columbia University
Expires: September 24, 2009                               March 23, 2009


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

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 24, 2009.

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

   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,



Forte & Schulzrinne    Expires September 24, 2009               [Page 1]


Internet-Draft               LoST Extensions                  March 2009


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


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.  Nw Use of Shapes in Queries  . . . . . . . . . . . . . . .  4
   6.  Limiting the Number of Returned Service URIs . . . . . . . . .  5
   7.  The <serviceLocation> Element in Responses . . . . . . . . . .  7
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  LoST Extensions Relax NG Schema Registration . . . . . . .  9
     9.2.  LoST Extensions Namespace Registration . . . . . . . . . .  9
   10. Non-Normative RELAX NG Schema in XML Syntax  . . . . . . . . . 10
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11



























Forte & Schulzrinne    Expires September 24, 2009               [Page 2]


Internet-Draft               LoST Extensions                  March 2009


1.  Introduction

   The Location-to-Service Translation (LoST) protocol [RFC5222] 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 [RFC5222].  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, in many cases service



Forte & Schulzrinne    Expires September 24, 2009               [Page 3]


Internet-Draft               LoST Extensions                  March 2009


   regions will be of little or no use.


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

   We introduce two new types of querie, "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 the <limit>
   element.

   Also, 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.  Nw Use of Shapes 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 the present context, rather than seeing such shapes as
   an area of uncertainty for the physical location of the client, we
   see them as the area within which we want to find a service.

   For example, 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 200 meters from our approximate position
   specified in <p2:pos>.

   Aside from the circular shape, other shapes are also useful.  In
   particular, there are situations in which it is useful to query for
   services in a certain direction of movement rather than in an exact
   physical location.  For example, if a user is driving North from New



Forte & Schulzrinne    Expires September 24, 2009               [Page 4]


Internet-Draft               LoST Extensions                  March 2009


   York City to Boston, it would be useful for this user to be able to
   query for services North of where he currently is, that is not in his
   current physical location nor at his final destination.

   In order to do this, we use shapes such as an ellipse.  The ellipse
   has a major and a minor dimension thus allowing for defining a
   "priviledged" direction by having the major dimension in the
   direction of movement.  This concept is similar to the one of
   omnidirectional versus directional antennas, where a device can see
   in either all directions or a specific direction, respectively.  In
   the present context the circular shape allows a device to search for
   services in any direction sourrounding its physical location while
   shapes such as the ellipse allow the device to search for services in
   a more specific direction.  The ellipse shape is defined in
   [PIDF-LO].


   <?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">
            200
         </p2:radius>
       </p2:Circle>
     </location>
     <service>urn:service:local.pizza</service>
   </findService>


   Figure 1: A 'within distance X' <findService> geodetic query using
   the circular shape


6.  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 define a new namespace
   "ext" for Lost extensions and introduce a new element, namely <ext:
   limit>, conveyed inside the <findService> element defined in
   [RFC5222].  Figures 2 and 3 show a <findService> geodetic query where



Forte & Schulzrinne    Expires September 24, 2009               [Page 5]


Internet-Draft               LoST Extensions                  March 2009


   the client asks the server to return no more than 20 service URIs.
   In particular, Figure 2 shows a 'N closest' query while Figure 3
   shows a query which is a combination of 'N closest' and 'within
   distance X'.  When receiving such queries, 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.

   <?xml version="1.0" encoding="UTF-8"?>
   <findService xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"
     xmlns:ext="http://www.thisisnotdoneyet.net"
     serviceBoundary="value" recursive="true">
     <ext:limit>20</ext:limit>
     <location id="6020688f1ce1896d" profile="geodetic-2d">
       <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
         <p2:pos>40.7128 -74.0092</p2:pos>
       </p2:Point>
     </location>
   <service>urn:service:food.pizza</service>
   </findService>

   Figure 2: A 'N closest' <findService> geodetic query with the new
   <limit> element


   <?xml version="1.0" encoding="UTF-8"?>
   <findService
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"
     xmlns:ext="http://www.thisisnotdoneyet.net"
     serviceBoundary="value"
     recursive="true">
     <ext:limit>20</ext:limit>
     <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">
            200
         </p2:radius>
       </p2:Circle>
     </location>
     <service>urn:service:local.pizza</service>
   </findService>





Forte & Schulzrinne    Expires September 24, 2009               [Page 6]


Internet-Draft               LoST Extensions                  March 2009


   Figure 3: A <findService> geodetic query with the new <limit>
   element.  This query is a combination of 'N closest' and 'within
   distance X' queries.


7.  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> [RFC5222], 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 SHOULD be
   used as the computation of the distance, route and other metrics
   would at some point require geocoding of the civic address in
   geodetic coordinates.  Because of this, the position specified in
   <serviceLocation> SHOULD be represented by using the <Point> element.
   The <Point> element is described in Section 12.2 of [RFC5222] and in
   Section 5.2.1 of [PIDF-LO].  Figure 4 shows a <findServiceResponse>
   answer containing two location-to-service-URI mappings.

   Since service regions are not relevant in the present context, they
   are not present in the response.

   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.

   There are situations, however, in which it is helpful to include a
   civic address together with the geodetic coordinates of a point of
   service.  Usually, databases already contain the civic address of
   points of interest and for devices with limited capabilities it is
   not always possible to perform decoding of geocoordinates in order to
   determine the civic address.  Because of this, including also the
   civic address in a response, can be useful.  In order to do this, we
   include the <civicAddress> element as defined in [RFC5139] in each
   <mapping> element.  Figure 4 shows a <findServiceResponse> answer
   with the <civicAddress> element.


      <?xml version="1.0" encoding="UTF-8"?>
      <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"



Forte & Schulzrinne    Expires September 24, 2009               [Page 7]


Internet-Draft               LoST Extensions                  March 2009


        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>
          <civicAddress
              xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
              <country>US</country>
              <A1>New York</A1>
              <A3>New York</A3>
              <A6>Broadway</A6>
              <HNO>321</HNO>
              <PC>10027</PC>
          </civicAddress>
        </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>
          <civicAddress
              xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
              <country>US</country>



Forte & Schulzrinne    Expires September 24, 2009               [Page 8]


Internet-Draft               LoST Extensions                  March 2009


              <A1>New York</A1>
              <A3>New York</A3>
              <A6>Amsterdam Avenue</A6>
              <HNO>123</HNO>
              <PC>10027</PC>
          </civicAddress>
        </mapping>
        <path>
          <via source="resolver.example"/>
          <via source="authoritative.example"/>
        </path>
        <locationUsed id="6020688f1ce1896d"/>
      </findServiceResponse>


   Figure 4: A <findServiceResponse> answer


8.  Security Considerations

   The same security considerations as in [RFC5222] apply.


9.  IANA Considerations

9.1.  LoST Extensions Relax NG Schema Registration

   TODO.

9.2.  LoST Extensions Namespace Registration

   TODO.



















Forte & Schulzrinne    Expires September 24, 2009               [Page 9]


Internet-Draft               LoST Extensions                  March 2009


10.  Non-Normative RELAX NG Schema in XML Syntax


     <?xml version="1.0" encoding="UTF-8"?>
     <grammar ns="urn:ietf:params:xml:ns:lost1"
       xmlns="http://relaxng.org/ns/structure/1.0"
       xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
       xmlns:ls="urn:ietf:params:xml:ns:lost1"
       datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

     <div>
       <ls:mapping>
         ...
         ...
         <a:documentation>
           Location information about the returned point of service.
         </a:documentation>

         <define name="serviceLocation">
           <element name="serviceLocation">
             <ref name="ls:locationInformation"/>
           </element>
         </define>
       </ls:mapping>
     </div>

     <div xmlns:ext="http://www.thisisnotdoneyet.net">
       <a:documentation>
         A limit to the number of returned results.
       </a:documentation>

       <define name="ext:limit">
         <element name="ext:limit">
           <data type="positiveInteger"/>
         </element>
       </define>
     </div>

       >


11.  References

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

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation



Forte & Schulzrinne    Expires September 24, 2009              [Page 10]


Internet-Draft               LoST Extensions                  March 2009


              Protocol", RFC 5222, August 2008.

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, 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 24, 2009              [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/