--- 1/draft-ietf-ecrit-lost-servicelistboundary-04.txt 2010-12-16 11:16:16.000000000 +0100 +++ 2/draft-ietf-ecrit-lost-servicelistboundary-05.txt 2010-12-16 11:16:16.000000000 +0100 @@ -1,18 +1,18 @@ ECRIT K. Wolf Internet-Draft nic.at -Intended status: Experimental August 6, 2010 -Expires: February 7, 2011 +Intended status: Experimental December 16, 2010 +Expires: June 19, 2011 LoST Service List Boundary Extension - draft-ietf-ecrit-lost-servicelistboundary-04 + draft-ietf-ecrit-lost-servicelistboundary-05 Abstract LoST maps 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 query to the LoST server. However, the LoST server, in its response, does not provide context information, that is, it does not provide any additional information about the geographical region for which the returned list of services is considered valid within. Therefore, @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on February 7, 2011. + This Internet-Draft will expire on June 19, 2011. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -88,20 +88,25 @@ 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 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 Points (PSAPs) only serve a specific geographic region. Therefore the LoST protocol [RFC5222] defines the Service Boundary, 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 query in LoST. The LoST server returns a list of services that are available at this particular location. But the server does not inform the client as to the extent of coverage for which geographical region the returned Service List is valid. @@ -120,46 +125,40 @@ urn:service:sos.police urn:service:sos.ambulance urn:service:sos.fire The client does the initial LoST mapping and discovers the dialstrings for each service. Then the client moves, refreshing the individual service mappings when necessary as told by the Service Boundary. However, when arriving in location B (close to a mountain), service sos.mountainrescue is available, which was not - available in location A. Nevertheless, the client does not detect - this, because only the mapping of the initially discovered services - (police, ambulance, fire) are refreshed. Consequently, the - dialstring for the mountain rescue is not known by the client. - Hence, the client is unable to recognize an emergency call when the - user enters the dialstring of the mountain rescue and thus the - emergency call may fail altogether. + available in location A. Since the client is only required to refresh + the mappings for the initially discovered services, the new service + is not detected. Consequently, the dialstring for the mountain + rescue is not known by the client. Hence, the client is unable to + recognize an emergency call when the user enters the dialstring of + the mountain rescue and thus the emergency call may fail altogether. Note that the Service Boundary (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 Service Boundary 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: o clients continuously poll for the Service List, although it may not have changed o a boundary information (telling the client that the Service List 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 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 extensions to the LoST protocol in order to support the proposed Service List Boundary in a similar @@ -327,21 +326,21 @@ may be different at different locations. The server MAY return the boundary information in multiple location 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 boundary information. There is no need to include boundary information to a . The request is purely for 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 server may return it or not based on its local policy - like it is the case with the Service Boundary. However, especially for emergency services, the Service List Boundary might be crucial to ensure that moving clients do not miss changes in the available services. 3.4. Implementation Considerations