Network Working Group A. Forte Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia University Expires: February 24, 2011 August 23, 2010 Location-to-Service Translation Protocol (LoST) Extensions draft-forte-lost-extensions-01.txt 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 of the type "N nearest", "within distance X" and "served by". 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 February 24, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Forte & Schulzrinne Expires February 24, 2011 [Page 1] Internet-Draft LoST Extensions August 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Service Regions . . . . . . . . . . . . . . . . . . . . . . . 3 4. New Query Types: "N nearest", "within distance X" and "served by" . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 5 5.2. Queries Based on Service Regions . . . . . . . . . . . . . 6 5.3. Difference Between "within distance X" and "served by" Queries . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Limiting the Number of Returned Service URIs . . . . . . . 8 5.5. The Element in Responses . . . . . . . . 10 6. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8.1. LoST Extensions Relax NG Schema Registration . . . . . . . 14 8.2. LoST Extensions Namespace Registration . . . . . . . . . . 15 9. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Forte & Schulzrinne Expires February 24, 2011 [Page 2] Internet-Draft LoST Extensions August 2010 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 three additional queries, giving the protocol the ability to find the N nearest instances of a particular service, all services within a given radius and all services whose service region includes the client's current location. The LoST extensions defined in this document do not apply to emergency services. 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 Regions Generally speaking, service regions apply only to a subset of services. In Section 1 of [RFC5222] a service region is defined as follows: "To minimize round trips and to provide robustness against network failures, LoST supports caching of individual mappings and indicates the region for which the same answer would be returned ("service region")." and in Section 5.5 of [RFC5222]: Forte & Schulzrinne Expires February 24, 2011 [Page 3] Internet-Draft LoST Extensions August 2010 "A response MAY indicate the region for which the service URL returned would be the same as in the actual query, the so-called service region." Given that for non-emergency services for each query we could get a large number of service URLs, a service region as per definition above would be the region within which a user would get the same set of service URLs. If one or more of the URLs in the set changes, the set of URLs changes that is, the service region changes. Therefore, for non-emergency services we can distinguish two types of service regions. One is the region served by the single POI (e.g., pizza delivery), the other one is according to the definition in [RFC5222] the region within which the client would always get the same set of service URLs. The second type of service region includes multiple service regions of the first type. Because of this, the service region as defined in [RFC5222] would change very frequently, making the use of service regions as described in [RFC5222] not that useful. This difference between emergency and non-emergency services is due to the fact that PSAPs have service regions that do not overlap significantly with one another and one service region is served by a single PSAP. As explained above, this is not the case for non- emergency services. Generally speaking, we can divide location-based services into two main categories. Services based on: o how far they are from the user (e.g., ATM machines, takeout) o whether or not their service region includes the client's current location (e.g., pizza delivery, NG9-1-1) For services included in the first category service regions are not relevant while they are important for services included in the second category. This distinction becomes obvious if we consider the difference between takeout (first category) and delivery (second category), for example. In the case of takeout, the user wants to go to a particular restaurant and buy dinner regardless of his location falling in the restaurant service region or not. For delivery the user cares about the restaurant service region as the restaurant will deliver food to him only if the user's location falls within the restaurant service region. There is a clear distinction between services that require service regions and services that do not. The LoST extensions defined in this document take this into account by using the service classification mentioned above. Forte & Schulzrinne Expires February 24, 2011 [Page 4] Internet-Draft LoST Extensions August 2010 4. New Query Types: "N nearest", "within distance X" and "served by" We introduce three new types of queries, "N nearest", "within distance X" and "served by". The first query returns the N points of interest closest to the client's physical location, the second query discovers all those points of interest located within a given distance from the client's physical location, the third query returns all those points of interest whose service region includes the client's current 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 various shapes [PIDF-LO] in LoST queries. For queries "served by", the LoST client needs to let the server know that it MUST return only those services whose service region includes the client's current location. In order to do this we introduce the element in queries. Service region boundaries MAY be returned in a LoST as described in [RFC5222]. 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 element in queries. Also, we introduce a new element in LoST responses, namely . 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. The new elements , and are defined in the "lostNe" namespace. This new namespace is defined in Section 6. 5.1. New 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. While this remains true for "served by" queries, for "within distance X" queries such shapes represent the area within which we want to find a service. For example, Figure 1 shows a geodetic query using the Forte & Schulzrinne Expires February 24, 2011 [Page 5] Internet-Draft LoST Extensions August 2010 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 . 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 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 at 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. 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]. 37.775 -122.422 200 urn:service:local.pizza Figure 1: A 'within distance X' geodetic query using the circular shape 5.2. Queries Based on Service Regions As mentioned in Section 1, we can divide location-based services into two main categories. Forte & Schulzrinne Expires February 24, 2011 [Page 6] Internet-Draft LoST Extensions August 2010 Services based on: o how far they are from the user o wether or not their service region includes the client's current location A "within distance X" query addresses services included in the first category while a "served by" query addresses services included in the second category. When querying LoST regarding a specific service, we need to specify if such service belongs to either the first or the second category. This is necessary since depending on the category the service belongs to, the LoST server has to follow a different metric in selecting the results to include in the response. In order for the client to specify which of the two categories the service belongs to, we introduce the element. This new element is of type boolean. When its value is true it means that the requested service belongs to the second category and a search based on service regions MUST be performed by the LoST server. When either its value is false or the element is missing, the LoST server MUST perform a search based on the distance between the user and the points of service. For a search based on service regions the LoST server MUST return only those services whose service region includes the client's current location. Service region boundaries MAY be returned in a LoST as described in [RFC5222]. true 37.775 -122.422 200 urn:service:local.pizza Figure 2: A 'served by' geodetic query with the new Forte & Schulzrinne Expires February 24, 2011 [Page 7] Internet-Draft LoST Extensions August 2010 element 5.3. Difference Between "within distance X" and "served by" Queries Figures 1 and 2 show an example of a "within distance X" query and a "served by" query, respectively. The two types of queries although very similar have three important differences. o A "served by" query can support all the shapes a "within distance X" query can support plus the point shape which does not make sense for a "within distance X" query. o In a "within distance X" query a shape represents the area within which to search for points of service. In all other types of queries including a "served by" query, a shape represents an uncertainty in the location of the client. o In a "within distance X" query the value of the element, if present, MUST be false. If such element is not present, its value MUST be assumed equal to false. A "served by" query SHALL have the value of the element always set to true. 5.4. Limiting the Number of Returned Service URIs Limiting the number of results is helpful, particularly for mobile devices with limited bandwidth. For "N nearest" 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 element, namely . This new element is OPTIONAL but when present, it MUST be conveyed inside the element defined in [RFC5222]. Figures 3, 4 and 5 show a geodetic query where the client asks the server to return no more than 20 service URIs. In particular, Figure 3 shows a 'N nearest' query, Figure 4 shows a query which is a combination of 'N nearest' and 'within distance X' while Figure 5 shows a query which is a combination of 'N nearest' and 'served by'. 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 among the points of interest to return, the N points of interest closest to the client's physical location and MUST return those in the response. When the element is not present in a query then all available points of interest for the requested type of service SHALL be returned by the LoST server. Forte & Schulzrinne Expires February 24, 2011 [Page 8] Internet-Draft LoST Extensions August 2010 20 40.7128 -74.0092 urn:service:food.pizza Figure 3: A 'N nearest' geodetic query with the new element false 20 37.775 -122.422 200 urn:service:local.pizza Figure 4: A geodetic query with the new and elements. This query is a combination of 'N nearest' and 'within distance X' queries. Forte & Schulzrinne Expires February 24, 2011 [Page 9] Internet-Draft LoST Extensions August 2010 true 20 37.775 -122.422 100 urn:service:local.pizza Figure 5: A geodetic query with the new and elements. This query is a combination of 'N nearest' and 'served by' queries. 5.5. The 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 . The element contains the geodetic coordinates of a point of service and SHOULD be used for all non-emergency services. When it is used, it MUST be contained in a element. In responses such as [RFC5222], a list of service URIs, each with its own element, SHOULD be returned. The order of service URIs in the list is not relevant. The 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 SHOULD be represented by using the element. The element is described in Section 12.2 of [RFC5222] and in Section 5.2.1 of [PIDF-LO]. Figure 6 shows a answer containing two location-to-service-URI mappings. [NOTE: The element cannot be extended for this purpose Forte & Schulzrinne Expires February 24, 2011 [Page 10] Internet-Draft LoST Extensions August 2010 as it is defined outside of the element. In particular, in a response the 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, it is RECOMMENDED to include the element as defined in [RFC5139] in each element. Figure 6 shows a answer with the element. Che bella pizza e all' anima da' pizza da Toto' urn:service:local.pizza sip:chebella@example.com xmpp:chebella@example.com 2129397040 33.665 -112.432 US New York New York Broadway 321 10027 King Mario's Pizza urn:service:local.pizza sip:marios@example.com xmpp:marios@example.com 2129397157 33.683 -112.412 US New York New York Amsterdam Avenue 123 10027 Figure 6: A answer 6. Relax NG Schema This section provides the Relax NG schema of LoST extensions in the compact form. The verbose form is included in Section 9. namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" default namespace ns1 = "urn:ietf:params:xml:ns:lostNe" ## ## Extensions to the Location-to-Service Translation (LoST) Forte & Schulzrinne Expires February 24, 2011 [Page 12] Internet-Draft LoST Extensions August 2010 ## Protocol ## ## LoST Extensions define three new elements: limit, region and ## serviceLocation. ## start = limit | region | serviceLocation ## ## A limit to the number of returned results. ## div { limit= element limit { xsd:positiveInteger } } ## ## A boolean variable to request a search ## based on either service regions or distance. ## div { region= element region { xsd:boolean } } ## ## Location Information ## div { locationInformation = extensionPoint+, attribute profile { xsd:NMTOKEN }? } ## ## Location Information about the returned point ## of service. ## div { serviceLocation= element serviceLocation { locationInformation }+ Forte & Schulzrinne Expires February 24, 2011 [Page 13] Internet-Draft LoST Extensions August 2010 } ## ## Patterns for inclusion of elements from schemas in ## other namespaces. ## div { ## ## Any element not in the LoST Extensions ## namespace. ## notLostExt = element * - (ns1:* | ns1:*) { anyElement } ## ## A wildcard pattern for including any element ## from any other namespace. ## anyElement = (element * { anyElement } | attribute * { text } | text)* ## ## A point where future extensions ## (elements from other namespaces) ## can be added. ## extensionPoint = notLostExt* } 7. Security Considerations The same security considerations as in [RFC5222] apply. 8. IANA Considerations 8.1. LoST Extensions Relax NG Schema Registration URI: urn:ietf:params:xml:schema:lostNe Registrant Contact: Andrea G. Forte, andreaf@cs.columbia.edu, Henning Schulzrinne, hgs@cs.columbia.edu Relax NG Schema: The Relax NG schema to be registered is contained in Forte & Schulzrinne Expires February 24, 2011 [Page 14] Internet-Draft LoST Extensions August 2010 Section 6. Its first line is default namespace ns1 = "urn:ietf:params:xml:ns:lostNe" and its last line is } 8.2. LoST Extensions Namespace Registration URI: urn:ietf:params:xml:ns:lost1:ext Registrant Contact: Andrea G. Forte, andreaf@cs.columbia.edu, Henning Schulzrinne, hgs@cs.columbia.edu XML: BEGIN LoST Extensions Namespace

Namespace for LoST Extensions

urn:ietf:params:xml:ns:lostNe

See RFCXXXX.

END 9. Non-Normative RELAX NG Schema in XML Syntax Forte & Schulzrinne Expires February 24, 2011 [Page 15] Internet-Draft LoST Extensions August 2010 Extensions to the Location-to-Service Translation (LoST) Protocol. LoST Extensions define three new elements: limit, region and serviceLocation.
A limit to the number of returned results.
A boolean variable to request a search based on either service regions or distance.
Location Information Forte & Schulzrinne Expires February 24, 2011 [Page 16] Internet-Draft LoST Extensions August 2010
Location Information about the returned point of service.
Patterns for inclusion of elements from schemas in other namespaces. Any element not in the LoST Extensions namespace. A wildcard pattern for including any element from any other namespace. Forte & Schulzrinne Expires February 24, 2011 [Page 17] Internet-Draft LoST Extensions August 2010 A point where future extensions (elements from other namespaces) can be added.
10. 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 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. Forte & Schulzrinne Expires February 24, 2011 [Page 18] Internet-Draft LoST Extensions August 2010 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 February 24, 2011 [Page 19]