< draft-forte-ecrit-lost-extensions-01.txt   draft-forte-ecrit-lost-extensions-02.txt >
Network Working Group A. Forte Network Working Group A. Forte
Internet-Draft H. Schulzrinne Internet-Draft H. Schulzrinne
Intended status: Standards Track Columbia University Intended status: Standards Track Columbia University
Expires: May 7, 2009 November 3, 2008 Expires: September 24, 2009 March 23, 2009
Location-to-Service Translation Protocol (LoST) Extensions Location-to-Service Translation Protocol (LoST) Extensions
draft-forte-ecrit-lost-extensions-01.txt draft-forte-ecrit-lost-extensions-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. 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 Abstract
An important class of location-based services answer the question An important class of location-based services answer the question
"What instances of this service are closest to me?" Examples include "What instances of this service are closest to me?" Examples include
finding restaurants, gas stations, stores, automated teller machines, finding restaurants, gas stations, stores, automated teller machines,
wireless access points (hot spots) or parking spaces. Currently, the wireless access points (hot spots) or parking spaces. Currently, the
Location-to-Service Translation (LoST) protocol only supports mapping Location-to-Service Translation (LoST) protocol only supports mapping
locations to a single service based on service regions. This locations to a single service based on service regions. This
document describes an extension that allows queries "N nearest" and document describes an extension that allows queries "N nearest" and
"within distance X". "within distance X".
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Service Region . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Service Region . . . . . . . . . . . . . . . . . . . . . . . . 3
4. New Query Types: "N nearest" and "within distance X" . . . . . 4 4. New Query Types: "N nearest" and "within distance X" . . . . . 4
5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 5. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. New Use of Circular Shape in Queries . . . . . . . . . . . 4 5.1. Nw Use of Shapes in Queries . . . . . . . . . . . . . . . 4
5.2. Limiting the Number of Returned Service URIs . . . . . . . 5 6. Limiting the Number of Returned Service URIs . . . . . . . . . 5
5.3. The <serviceLocation> Element in Responses . . . . . . . . 6 7. The <serviceLocation> Element in Responses . . . . . . . . . . 7
6. Distance Calculation: General Considerations . . . . . . . . . 9
7. Complex Queries . . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9.1. LoST Extensions Relax NG Schema Registration . . . . . . . 10 9.1. LoST Extensions Relax NG Schema Registration . . . . . . . 9
9.2. LoST Extensions Namespace Registration . . . . . . . . . . 10 9.2. LoST Extensions Namespace Registration . . . . . . . . . . 9
10. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 10 10. Non-Normative RELAX NG Schema in XML Syntax . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
The Location-to-Service Translation (LoST) protocol [RFC5222] maps The Location-to-Service Translation (LoST) protocol [RFC5222] maps
service identifiers (URNs) and civic or geospatial information to service identifiers (URNs) and civic or geospatial information to
service URIs, based on service regions. While motivated by mapping service URIs, based on service regions. While motivated by mapping
locations to the public safety answering point (PSAP) serving that locations to the public safety answering point (PSAP) serving that
location, the protocol has been designed to generalize to other location, the protocol has been designed to generalize to other
location mapping services. location mapping services.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
is given by jurisdictional boundaries, but does not work as well for is given by jurisdictional boundaries, but does not work as well for
other services that do not have clearly defined boundaries. For other services that do not have clearly defined boundaries. For
example, any given location is likely served by a number of different example, any given location is likely served by a number of different
restaurants, depending on how far the prospective customer is willing restaurants, depending on how far the prospective customer is willing
to walk or drive. to walk or drive.
We extend LoST with two additional queries, giving the protocol the We extend LoST with two additional queries, giving the protocol the
ability to find the N nearest instances of a particular service and ability to find the N nearest instances of a particular service and
all services within a given radius. all services within a given radius.
2. Requirements notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Service Region 3. Service Region
In the LoST protocol, the <findServiceResponse> message includes a In the LoST protocol, the <findServiceResponse> message includes a
service region [RFC5222]. This is the geographical area for which a service region [RFC5222]. This is the geographical area for which a
query will always receive the same response. Because of this, the query will always receive the same response. Because of this, the
skipping to change at page 3, line 50 skipping to change at page 3, line 50
In emergency services, as soon as the service region changes, the In emergency services, as soon as the service region changes, the
client queries the LoST server in order to discover the new PSAP. client queries the LoST server in order to discover the new PSAP.
This is important since clients need to know their PSAP before an This is important since clients need to know their PSAP before an
emergency occurs, so that no time is wasted in discovering the emergency occurs, so that no time is wasted in discovering the
correct PSAP during the emergency. correct PSAP during the emergency.
Other location-based services are not as critical as emergency Other location-based services are not as critical as emergency
services, and points of interest can be discovered on demand, at the services, and points of interest can be discovered on demand, at the
time they are needed and not before. Because of this, for location- time they are needed and not before. Because of this, for location-
based services other than emergency services, service regions will be based services other than emergency services, in many cases service
of little or no use. regions will be of little or no use.
4. New Query Types: "N nearest" and "within distance X" 4. New Query Types: "N nearest" and "within distance X"
The two new types of queries we introduce are "N nearest" and "within We introduce two new types of querie, "N nearest" and "within
distance X". The former returns the N points of interest closest to distance X". The former returns the N points of interest closest to
the client's physical location, the latter discovers all those points the client's physical location, the latter discovers all those points
of interest residing within a given distance from the client's of interest residing within a given distance from the client's
physical location. physical location.
5. LoST Extensions 5. LoST Extensions
For queries "within distance X", the LoST client needs to specify to For queries "within distance X", the LoST client needs to specify to
the server the range within which instances of a particular service 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 should be searched. In order to do this, we make use of the circular
skipping to change at page 4, line 32 skipping to change at page 4, line 32
N, that is, the maximum number of service URIs to be returned in a N, that is, the maximum number of service URIs to be returned in a
response. In order to specify this, we introduce the <limit> response. In order to specify this, we introduce the <limit>
element. element.
Also, we introduce a new element in LoST responses, namely Also, we introduce a new element in LoST responses, namely
<serviceLocation>. This new element is used by the server to <serviceLocation>. This new element is used by the server to
indicate to the client the physical location of points of interest. indicate to the client the physical location of points of interest.
In doing so, the client can compute the distance and other metrics In doing so, the client can compute the distance and other metrics
between its current location and the points of interest. between its current location and the points of interest.
5.1. New Use of Circular Shape in Queries 5.1. Nw Use of Shapes in Queries
In [PIDF-LO] different shapes are defined in order to represent a In [PIDF-LO] different shapes are defined in order to represent a
point and an area of uncertainty within which the user might be point and an area of uncertainty within which the user might be
situated. In order to extend LoST to support "N nearest" and "within situated. In the present context, rather than seeing such shapes as
distance X" queries, we use the PIDF-LO circular shape [PIDF-LO]. In an area of uncertainty for the physical location of the client, we
the present context, rather than seeing the circle as an area of see them as the area within which we want to find a service.
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 For example, Figure 1 shows a <findService> geodetic query using the
shape. In particular, with the query shown in Figure 1, we are circular shape. In particular, with the query shown in Figure 1, we
asking the LoST server to send us a list of service URNs for pizza are asking the LoST server to send us a list of service URNs for
places within 850.24 meters from our approximate position specified pizza places within 200 meters from our approximate position
in <p2:pos>. 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
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"?> <?xml version="1.0" encoding="UTF-8"?>
<findService <findService
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" xmlns:p2="http://www.opengis.net/gml"
serviceBoundary="value" serviceBoundary="value"
recursive="true"> recursive="true">
<location id="6020688f1ce1896d" profile="geodetic-2d"> <location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <p2:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos> <p2:pos>37.775 -122.422</p2:pos>
<p2:radius uom="urn:ogc:def:uom:EPSG::9001"> <p2:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24 200
</p2:radius> </p2:radius>
</p2:Circle> </p2:Circle>
</location> </location>
<service>urn:service:local.pizza</service> <service>urn:service:local.pizza</service>
</findService> </findService>
Figure 1: A 'within distance X' <findService> geodetic query using Figure 1: A 'within distance X' <findService> geodetic query using
the circular shape the circular shape
5.2. Limiting the Number of Returned Service URIs 6. Limiting the Number of Returned Service URIs
Limiting the number of results is helpful, particularly for mobile Limiting the number of results is helpful, particularly for mobile
devices with limited bandwidth. For "N closest" queries, the client 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 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 URIs. In order to specify such limit, we define a new namespace
"ext" for Lost extensions and introduce a new element, namely <ext: "ext" for Lost extensions and introduce a new element, namely <ext:
limit>, conveyed inside the <findService> element defined in limit>, conveyed inside the <findService> element defined in
[RFC5222]. Figures 2 and 3 show a <findService> geodetic query where [RFC5222]. Figures 2 and 3 show a <findService> geodetic query where
the client asks the server to return no more than 20 service URIs. 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 In particular, Figure 2 shows a 'N closest' query while Figure 3
skipping to change at page 6, line 34 skipping to change at page 6, line 43
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" xmlns:p2="http://www.opengis.net/gml"
xmlns:ext="http://www.thisisnotdoneyet.net" xmlns:ext="http://www.thisisnotdoneyet.net"
serviceBoundary="value" serviceBoundary="value"
recursive="true"> recursive="true">
<ext:limit>20</ext:limit> <ext:limit>20</ext:limit>
<location id="6020688f1ce1896d" profile="geodetic-2d"> <location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <p2:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos> <p2:pos>37.775 -122.422</p2:pos>
<p2:radius uom="urn:ogc:def:uom:EPSG::9001"> <p2:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24 200
</p2:radius> </p2:radius>
</p2:Circle> </p2:Circle>
</location> </location>
<service>urn:service:local.pizza</service> <service>urn:service:local.pizza</service>
</findService> </findService>
Figure 3: A <findService> geodetic query with the new <limit> Figure 3: A <findService> geodetic query with the new <limit>
element. This query is a combination of 'N closest' and 'within element. This query is a combination of 'N closest' and 'within
distance X' queries. distance X' queries.
5.3. The <serviceLocation> Element in Responses 7. The <serviceLocation> Element in Responses
It is important for the LoST client to know the location of a point 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 of interest so that distance, route and other metrics can be
computed. We introduce a new element, namely <serviceLocation>. The computed. We introduce a new element, namely <serviceLocation>. The
<serviceLocation> element contains the geodetic coordinates of a <serviceLocation> element contains the geodetic coordinates of a
point of service and MUST be contained in a <mapping> element. In point of service and MUST be contained in a <mapping> element. In
responses such as <findServiceResponse> [RFC5222], a list of service responses such as <findServiceResponse> [RFC5222], a list of service
URIs, each with its own <serviceLocation> element, MUST be returned. URIs, each with its own <serviceLocation> element, MUST be returned.
The order of service URIs in the list is not relevant. The order of service URIs in the list is not relevant.
The <serviceLocation> element has one single attribute, 'profile', in The <serviceLocation> element has one single attribute, 'profile', in
order to specify the profile used. Only geodetic profiles SHOULD be order to specify the profile used. Only geodetic profiles SHOULD be
used as the computation of the distance, route and other metrics used as the computation of the distance, route and other metrics
would at some point require geocoding of the civic address in would at some point require geocoding of the civic address in
geodetic coordinates. Because of this, the position specified in geodetic coordinates. Because of this, the position specified in
<serviceLocation> SHOULD be represented by using the <Point> element. <serviceLocation> SHOULD be represented by using the <Point> element.
The <Point> element is described in Section 12.2 of [RFC5222] and in 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> Section 5.2.1 of [PIDF-LO]. Figure 4 shows a <findServiceResponse>
answer containing two location-to-service-URI mappings. answer containing two location-to-service-URI mappings.
It is important to notice that since service regions are not relevant Since service regions are not relevant in the present context, they
in the present context, they are not present in the response. are not present in the response.
NOTE: The <locationUsed> element cannot be extended for this purpose NOTE: The <locationUsed> element cannot be extended for this purpose
as it is defined outside of the <mapping> element. In particular, in as it is defined outside of the <mapping> element. In particular, in
a response the <locationUsed> element is always one, while the number a response the <locationUsed> element is always one, while the number
of service URIs is typically more than one. of service URIs is typically more than one.
There are situations, however, in which it is helpful to include a There are situations, however, in which it is helpful to include a
civic address together with the geodetic coordinates of a point of civic address together with the geodetic coordinates of a point of
service. Usually, databases already contain the civic address of service. Usually, databases already contain the civic address of
points of interest and for devices with limited capabilities it is points of interest and for devices with limited capabilities it is
skipping to change at page 9, line 9 skipping to change at page 9, line 20
</mapping> </mapping>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="6020688f1ce1896d"/> <locationUsed id="6020688f1ce1896d"/>
</findServiceResponse> </findServiceResponse>
Figure 4: A <findServiceResponse> answer Figure 4: A <findServiceResponse> answer
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 8. Security Considerations
The same security considerations as in [RFC5222] apply. The same security considerations as in [RFC5222] apply.
9. IANA Considerations 9. IANA Considerations
9.1. LoST Extensions Relax NG Schema Registration 9.1. LoST Extensions Relax NG Schema Registration
TODO. TODO.
skipping to change at page 12, line 4 skipping to change at line 455
Email: andreaf@cs.columbia.edu Email: andreaf@cs.columbia.edu
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
1214 Amsterdam Avenue, MC 0401 1214 Amsterdam Avenue, MC 0401
New York, NY 10027 New York, NY 10027
USA USA
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
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.
 End of changes. 23 change blocks. 
76 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/