draft-ietf-ecrit-lost-servicelistboundary-04.txt   draft-ietf-ecrit-lost-servicelistboundary-05.txt 
ECRIT K. Wolf ECRIT K. Wolf
Internet-Draft nic.at Internet-Draft nic.at
Intended status: Experimental August 6, 2010 Intended status: Experimental December 16, 2010
Expires: February 7, 2011 Expires: June 19, 2011
LoST Service List Boundary Extension LoST Service List Boundary Extension
draft-ietf-ecrit-lost-servicelistboundary-04 draft-ietf-ecrit-lost-servicelistboundary-05
Abstract Abstract
LoST maps service identifiers and location information to service LoST maps service identifiers and location information to service
contact URIs. If a LoST client wants to discover available services contact URIs. If a LoST client wants to discover available services
for a particular location, it will perform a <listServicesByLocation> for a particular location, it will perform a <listServicesByLocation>
query to the LoST server. However, the LoST server, in its response, query to the LoST server. However, the LoST server, in its response,
does not provide context information, that is, it does not provide does not provide context information, that is, it does not provide
any additional information about the geographical region for which any additional information about the geographical region for which
the returned list of services is considered valid within. Therefore, the returned list of services is considered valid within. Therefore,
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 7, 2011. This Internet-Draft will expire on June 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 7 skipping to change at page 4, line 7
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Since the LoST protocol employs the Service Boundary concept in order
to avoid having clients continuously trying to refresh the mapping of
a specific service, a Service List Boundary mechanism provides
similar advantages for Service Lists.
Location based service providers as well as Public Safety Answering Location based service providers as well as Public Safety Answering
Points (PSAPs) only serve a specific geographic region. Therefore Points (PSAPs) only serve a specific geographic region. Therefore
the LoST protocol [RFC5222] defines the Service Boundary, which the LoST protocol [RFC5222] defines the Service Boundary, which
indicates the service region for a specific service URL. However, indicates the service region for a specific service URL. However,
not all services are available everywhere. Clients can discover not all services are available everywhere. Clients can discover
available services for a particular location by the available services for a particular location by the
<listServicesByLocation> query in LoST. The LoST server returns a <listServicesByLocation> query in LoST. The LoST server returns a
list of services that are available at this particular location. But list of services that are available at this particular location. But
the server does not inform the client as to the extent of coverage the server does not inform the client as to the extent of coverage
for which geographical region the returned Service List is valid. for which geographical region the returned Service List is valid.
skipping to change at page 4, line 39 skipping to change at page 4, line 44
urn:service:sos.police urn:service:sos.police
urn:service:sos.ambulance urn:service:sos.ambulance
urn:service:sos.fire urn:service:sos.fire
The client does the initial LoST mapping and discovers the The client does the initial LoST mapping and discovers the
dialstrings for each service. Then the client moves, refreshing the dialstrings for each service. Then the client moves, refreshing the
individual service mappings when necessary as told by the Service individual service mappings when necessary as told by the Service
Boundary. However, when arriving in location B (close to a Boundary. However, when arriving in location B (close to a
mountain), service sos.mountainrescue is available, which was not mountain), service sos.mountainrescue is available, which was not
available in location A. Nevertheless, the client does not detect available in location A. Since the client is only required to refresh
this, because only the mapping of the initially discovered services the mappings for the initially discovered services, the new service
(police, ambulance, fire) are refreshed. Consequently, the is not detected. Consequently, the dialstring for the mountain
dialstring for the mountain rescue is not known by the client. rescue is not known by the client. Hence, the client is unable to
Hence, the client is unable to recognize an emergency call when the recognize an emergency call when the user enters the dialstring of
user enters the dialstring of the mountain rescue and thus the the mountain rescue and thus the emergency call may fail altogether.
emergency call may fail altogether.
Note that the Service Boundary (service region for an individual Note that the Service Boundary (service region for an individual
service) cannot be considered as an indicator for the region a service) cannot be considered as an indicator for the region a
specific Service List is valid for. The Service List may even change specific Service List is valid for. The Service List may even change
within the Service Boundary of another service. For example, the within the Service Boundary of another service. For example, the
ambulance mapping is valid for a whole state, but for a part of the ambulance mapping is valid for a whole state, but for a part of the
state there is an additional mountain rescue service. state there is an additional mountain rescue service.
Consequently, there are two ways to tackle this issue: Consequently, there are two ways to tackle this issue:
o clients continuously poll for the Service List, although it may o clients continuously poll for the Service List, although it may
not have changed not have changed
o a boundary information (telling the client that the Service List o a boundary information (telling the client that the Service List
does not change inside this area) does not change inside this area)
Since the LoST protocol employs the Service Boundary concept in order
to avoid having clients continuously trying to refresh the mapping of
a specific service, a Service List Boundary mechanism would provide
similar advantages for Service Lists.
2. Terminology 2. Terminology
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. LoST Extensions 3. LoST Extensions
This chapter describes the necessary extensions to the LoST protocol This chapter describes the necessary extensions to the LoST protocol
in order to support the proposed Service List Boundary in a similar in order to support the proposed Service List Boundary in a similar
skipping to change at page 10, line 4 skipping to change at page 10, line 4
may be different at different locations. may be different at different locations.
The server MAY return the boundary information in multiple location The server MAY return the boundary information in multiple location
profiles, but MUST use at least one profile that the client used in profiles, but MUST use at least one profile that the client used in
the request in order to ensure that the client is able to process the the request in order to ensure that the client is able to process the
boundary information. boundary information.
There is no need to include boundary information to a There is no need to include boundary information to a
<listServicesResponse>. The <listServices> request is purely for <listServicesResponse>. The <listServices> request is purely for
diagnostic purposes and does not contain location information at all, diagnostic purposes and does not contain location information at all,
so no boundary information is reasonable. so boundary information cannot be calculated.
Also note that the Service List Boundary is optional and the LoST Also note that the Service List Boundary is optional and the LoST
server may return it or not based on its local policy - like it is server may return it or not based on its local policy - like it is
the case with the Service Boundary. However, especially for the case with the Service Boundary. However, especially for
emergency services, the Service List Boundary might be crucial to emergency services, the Service List Boundary might be crucial to
ensure that moving clients do not miss changes in the available ensure that moving clients do not miss changes in the available
services. services.
3.4. Implementation Considerations 3.4. Implementation Considerations
 End of changes. 7 change blocks. 
17 lines changed or deleted 16 lines changed or added

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