Network Working Group A. Forte Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia University Expires: October 2, 2010 March 31, 2010 Location-to-Service Translation Protocol (LoST) Extensions draft-forte-lost-extensions-00.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 October 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Forte & Schulzrinne Expires October 2, 2010 [Page 1] Internet-Draft LoST Extensions March 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. New Query Types: "N nearest", "within distance X" and "served by" . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. New Use of Shapes in Queries . . . . . . . . . . . . . . . 4 4.2. Queries Based on Service Areas . . . . . . . . . . . . . . 5 4.3. Difference Between "within distance X" and "served by" Queries . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Limiting the Number of Returned Service URIs . . . . . . . 7 4.5. The Element in Responses . . . . . . . . 9 5. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. LoST Extensions Relax NG Schema Registration . . . . . . . 13 7.2. LoST Extensions Namespace Registration . . . . . . . . . . 14 8. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Forte & Schulzrinne Expires October 2, 2010 [Page 2] Internet-Draft LoST Extensions March 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. 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 wether 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. 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]. Forte & Schulzrinne Expires October 2, 2010 [Page 3] Internet-Draft LoST Extensions March 2010 3. 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. 4. 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. 4.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 October 2, 2010 [Page 4] Internet-Draft LoST Extensions March 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 4.2. Queries Based on Service Areas As mentioned in Section 1, we can divide location-based services into two main categories. Forte & Schulzrinne Expires October 2, 2010 [Page 5] Internet-Draft LoST Extensions March 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 For services included in the first category a "within distance X" query MUST be used. For services included in the second category a "served by" query MUST be used. 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 October 2, 2010 [Page 6] Internet-Draft LoST Extensions March 2010 element 4.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. 4.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 October 2, 2010 [Page 7] Internet-Draft LoST Extensions March 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 October 2, 2010 [Page 8] Internet-Draft LoST Extensions March 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. 4.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 October 2, 2010 [Page 9] Internet-Draft LoST Extensions March 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 5. 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 October 2, 2010 [Page 11] Internet-Draft LoST Extensions March 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 areas 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 October 2, 2010 [Page 12] Internet-Draft LoST Extensions March 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* } 6. Security Considerations The same security considerations as in [RFC5222] apply. 7. IANA Considerations 7.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 October 2, 2010 [Page 13] Internet-Draft LoST Extensions March 2010 Section 6. Its first line is default namespace ns1 = "urn:ietf:params:xml:ns:lostNe" and its last line is } 7.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 8. Non-Normative RELAX NG Schema in XML Syntax Forte & Schulzrinne Expires October 2, 2010 [Page 14] Internet-Draft LoST Extensions March 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 areas or distance.
Location Information Forte & Schulzrinne Expires October 2, 2010 [Page 15] Internet-Draft LoST Extensions March 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 October 2, 2010 [Page 16] Internet-Draft LoST Extensions March 2010 A point where future extensions (elements from other namespaces) can be added.
9. 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 October 2, 2010 [Page 17] Internet-Draft LoST Extensions March 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 October 2, 2010 [Page 18]