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 <serviceLocation> 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
<region> element in <findService> queries. Service region boundaries
MAY be returned in a LoST <findServiceResponse> 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 <limit> element
in <findService> queries.
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.
The new elements <region>, <limit> and <findService> 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 <findService> 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 <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 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].
<?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
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 <region> 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 <region> 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 <findServiceResponse> as described in [RFC5222].
<?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/lostNe"
serviceBoundary="value" recursive="true">
<ext:region>true</ext:region>
<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 2: A 'served by' <findService> geodetic query with the new
Forte & Schulzrinne Expires February 24, 2011 [Page 7]
Internet-Draft LoST Extensions August 2010
<region> 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 <region> 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 <region> 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 <limit>. This new element is OPTIONAL but when present, it
MUST be conveyed inside the <findService> element defined in
[RFC5222].
Figures 3, 4 and 5 show a <findService> 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 <limit> element is not present in a <findService> 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
<?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/lostNe"
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 3: A 'N nearest' <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/lostNe"
serviceBoundary="value"
recursive="true">
<ext:region>false</ext:region>
<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>
Figure 4: A <findService> geodetic query with the new <limit> and
<region> 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
<?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/lostNe"
serviceBoundary="value"
recursive="true">
<ext:region>true</ext:region>
<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">
100
</p2:radius>
</p2:Circle>
</location>
<service>urn:service:local.pizza</service>
</findService>
Figure 5: A <findService> geodetic query with the new <limit> and
<region> elements. This query is a combination of 'N nearest' and
'served by' queries.
5.5. 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 SHOULD be used for all non-emergency services.
When it is used, it MUST be contained in a <mapping> element. In
responses such as <findServiceResponse> [RFC5222], a list of service
URIs, each with its own <serviceLocation> element, SHOULD 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 6 shows a <findServiceResponse>
answer containing two location-to-service-URI mappings.
[NOTE: The <locationUsed> 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 <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, it
is RECOMMENDED to include the <civicAddress> element as defined in
[RFC5139] in each <mapping> element. Figure 6 shows a
<findServiceResponse> answer with the <civicAddress> element.
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
xmlns:ext="http://www.thisisnotdoneyet.net/lostNe">
<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>
<ext: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>
</ext: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
Forte & Schulzrinne Expires February 24, 2011 [Page 11]
Internet-Draft LoST Extensions August 2010
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>
<ext: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>
</ext:serviceLocation>
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<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 6: A <findServiceResponse> 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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Extensions Namespace</title>
</head>
<body>
<h1>Namespace for LoST Extensions</h1>
<h2>urn:ietf:params:xml:ns:lostNe</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
END
9. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lostNe"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
Forte & Schulzrinne Expires February 24, 2011 [Page 15]
Internet-Draft LoST Extensions August 2010
<a:documentation>
Extensions to the Location-to-Service Translation (LoST)
Protocol.
LoST Extensions define three new elements: limit, region and
serviceLocation.
</a:documentation>
<choice>
<ref name="limit"/>
<reference name="region"/>
<ref name="serviceLocation"/>
</choice>
</start>
<div>
<a:documentation>
A limit to the number of returned results.
</a:documentation>
<define name="limit">
<element name="limit">
<data type="positiveInteger"/>
</element>
</define>
</div>
<div>
<a:documentation>
A boolean variable to request a search
based on either service regions or distance.
</a:documentation>
<define name="region">
<element name="region">
<data type="boolean"/>
</element>
</define>
</div>
<div>
<a:documentation>
Location Information
</a:documentation>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<optional>
Forte & Schulzrinne Expires February 24, 2011 [Page 16]
Internet-Draft LoST Extensions August 2010
<attribute name="profile">
<data type="NMTOKEN"/>
</attribute>
</optional>
</define>
</div>
<div>
<a:documentation>
Location Information about the returned point of service.
</a:documentation>
<define name="serviceLocation">
<element name="serviceLocation">
<ref name="locationInformation"/>
</element>
</define>
</div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<define name="notLostExt">
<a:documentation>
Any element not in the LoST Extensions namespace.
</a:documentation>
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:lostNe"/>
<nsName/>
</except>
</anyName>
<ref name="anyElement"/>
</element>
</define>
<define name="anyElement">
<a:documentation>
A wildcard pattern for including any element
from any other namespace.
</a:documentation>
<zeroOrMore>
<choice>
<element>
Forte & Schulzrinne Expires February 24, 2011 [Page 17]
Internet-Draft LoST Extensions August 2010
<anyName/>
<ref name="anyElement"/>
</element>
<attribute>
<anyName/>
</attribute>
<text/>
</choice>
</zeroOrMore>
</define>
<define name="extensionPoint">
<a:documentation>
A point where future extensions
(elements from other namespaces)
can be added.
</a:documentation>
<zeroOrMore>
<ref name="notLostExt"/>
</zeroOrMore>
</define>
</div>
</grammar>
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]
