ECRIT K. Wolf
Internet-Draft nic.at
Expires: November 29, 2008 May 28, 2008
Location-to-Service Translation Protocol (LoST) Extension:
ServiceListBoundary
draft-wolf-ecrit-lost-servicelistboundary-00
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 November 29, 2008.
Abstract
LoST [I-D.ietf-ecrit-lost] is able to map service identifiers and
location information to service contact URIs. If a LoST client wants
to discover available services for a particular location, it will
perform a <listServicesByLocation> query to the LoST server.
However, the response from the LoST server does not give information
about the geographical region, for which the returned service list is
valid. Therefore this document proposes a ServiceListBoundary, in
addition to the ServiceBoundary (which indicates the region a
specific service URL is valid).
Wolf Expires November 29, 2008 [Page 1]
Internet-Draft serviceListBoundary May 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. LoST Extensions . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Extensions to <ListServiceByLocation> . . . . . . . . . . . 4
3.2. Retrieving the serviceList Boundary via
getServiceListBoundary . . . . . . . . . . . . . . . . . . 5
3.3. Service List Boundary . . . . . . . . . . . . . . . . . . . 6
4. Security & Privacy Considerations . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Wolf Expires November 29, 2008 [Page 2]
Internet-Draft serviceListBoundary May 2008
1. Introduction
Location based service providers as well as Public Safety Answering
Points only serve a specific geographic region. Therefore the LoST
protocol defines the ServiceBoundary, which indicates the service
region for a specific service URL. However, not all services are
available everywhere. Clients can discover available services for a
particular location by the <listServicesByLocation> query. The LoST
server returns a list of services that are available at this
particular location. But the server does not inform the client, for
which geographical region the returned service list is valid. This
may lead to the situation where a client initially discovered all
available services by the <listServicesByLocation> query, and then
moves to a different location while refreshing the service mappings,
but does not notice the availability of another service. The
following imaginary example illustrates the problem for emergency
calling:
The client is powered-up, does location determination (resulting in
location A) and performs an initial <listServicesByLocation> query
with location A requesting urn:services:sos.
The LoST server returns the following services list:
urn:service:sos.police
urn:service:sos.ambulance
urn:service:sos.fire
The client does the initial LoST mapping and discovers the
dialstrings for these services. Then the client moves, refreshing
the service mappings when necessary as told by the ServiceBoundary.
However, when arriving in location B (close to a mountain), service:
sos:mountainrescue is available (which is not available in location
A). Nevertheless, the client does not detect this, because only the
initially learned services (police, ambulance, fire) are refreshed.
Consequently the dialstring for the mountainrescue is not known by
the client, and the emergency call to the mountainrescue will
certainly fail.
Note that the ServiceBoundary (service region for an individual
service) cannot be considered as an indicator for the region a
specific service list is valid for. The service list may even change
within the ServiceBoundary of another service. For example, the
ambulance mapping is valid for a whole state, but for a part of the
state there is an additional mountain rescue service.
Consequently, there are two ways to tackle this issue:
Wolf Expires November 29, 2008 [Page 3]
Internet-Draft serviceListBoundary May 2008
o clients continuously ask for the service list (although it may not
have changed)
o an additional boundary indicating the region, a specific service
list is valid for (in the style of the ServiceBoundary)
Since the LoST protocol has the ServiceBoundary concept in order to
avoid that clients continuously try to refresh the mapping of a
specific service, a ServiceListBoundary would provide a similar
mechanism for service lists.
2. Terminology
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 RFC 2119 [RFC2119].
3. LoST Extensions
This chapter describes the necessary modifications to the LoST
protocol in order to support the proposed ServiceListBoundary in a
similar way as the ServiceBoundary.
3.1. Extensions to <ListServiceByLocation>
The query <ListServicesByLocation> may contain an additional
serviceListBoundary attribute to request the boundary for the service
list returned, either by value or by reference.
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
serviceListBoundary="value"
recursive="true">
<location id="mylocation" profile="geodetic-2d">
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>48.1454 16.3774</gml:pos>
</gml:Point>
</location>
<service>urn:service:sos</service>
</listServicesByLocation>
A possible response is shown below:
Wolf Expires November 29, 2008 [Page 4]
Internet-Draft serviceListBoundary May 2008
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList expires="2010-01-01T00:00:00Z">
urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.poison
urn:service:sos.police
</serviceList>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="mylocation"/>
<serviceListBoundary
profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>AT</country>
<A1>Lower Austria</A1>
</civicAddress>
</serviceListBoundary>
</listServicesByLocationResponse>
This exemplary response indicates that the service list is valid for
Lower Austria. The <listServicesByLocation> request has to be
repeated only when moving out of Lower Austria. However, the
mappings of the services itself may have other service boundaries.
Additionally, the expires attribute indicates the absolute time when
this service list becomes invalid.
The boundary can also be requested by reference when setting the
attribute serviceListBoundary to "reference". Then the response
contains a serviceListBoundaryReference element:
<serviceListBoundaryReference
source="authoritative.example"
key="123567890123567890123567890" />
3.2. Retrieving the serviceList Boundary via getServiceListBoundary
In order to retrieve the boundary for a specific service list, the
client issues a <getServiceListBoundary> request, similar to the
<getServiceBoundary> request.
Wolf Expires November 29, 2008 [Page 5]
Internet-Draft serviceListBoundary May 2008
An example is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<getServiceListBoundary xmlns="urn:ietf:params:xml:ns:lost1"
key="123567890123567890123567890"/>
The LoST server response is shown below:
<?xml version="1.0" encoding="UTF-8"?>
<getServiceListBoundaryResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceBoundary profile="civic" expires="2010-01-01T00:00:00Z">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
</civicAddress>
</serviceBoundary>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</getServiceListBoundaryResponse>
3.3. Service List Boundary
The service list boundary indicates a region within which all
<listServicesByLocation> queries with the same service identifiers
result in the same serviceList. A service list boundary may consist
of geometric shapes (both in civic and geodetic location format), and
may be non-contiguous, like the service boundary.
The mapping of the specific services within the service list boundary
may be different at different locations.
There is no need to include boundary information to a
<listServiceResponse>. <ListServices> requests are purely for
diagnostic purposes and do not contain location information at all,
so no boundary information is reasonable.
4. Security & Privacy Considerations
Security considerations are discussed in [I-D.ietf-ecrit-lost].
Wolf Expires November 29, 2008 [Page 6]
Internet-Draft serviceListBoundary May 2008
5. IANA Considerations
TODO.
6. Normative References
[I-D.ietf-ecrit-lost]
Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-09 (work in progress),
March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Karl Heinz Wolf
nic.at GmbH
Karlsplatz 1/2/9
Wien A-1010
Austria
Phone: +43 1 5056416 37
Email: karlheinz.wolf@nic.at
URI: http://www.nic.at/
Wolf Expires November 29, 2008 [Page 7]
Internet-Draft serviceListBoundary May 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.
Wolf Expires November 29, 2008 [Page 8]