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]