LoST Service List Boundary Extension
draft-ietf-ecrit-lost-servicelistboundary-03

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 <listServicesByLocation> 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, this document proposes a <serviceListBoundary> element that returns a local context along with the list of services returned, in order to assist the client to not miss a change in available services when moving.

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 August 30, 2010.

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 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.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction

2.  Terminology

3.  LoST Extensions
    3.1.  Extensions to <listServicesByLocation>
    3.2.  Retrieving the <serviceListBoundary> via <getServiceListBoundary>
    3.3.  <serviceListBoundary>
    3.4.  Implementation Considerations
        3.4.1.  Server Side
        3.4.2.  Client Side

4.  Security & Privacy Considerations

5.  IANA Considerations
    5.1.  Relax NG Schema Registration
    5.2.  Namespace Registration

6.  Acknowledgement

7.  References
    7.1.  Normative References
    7.2.  Informative References

§  Author's Address

1.  Introduction

Location based service providers as well as Public Safety Answering Points (PSAPs) only serve a specific geographic region. Therefore the LoST protocol [RFC5222] (Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, “LoST: A Location-to-Service Translation Protocol,” August 2008.) 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 <listServicesByLocation> 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. This may lead to the situation where a client initially discovers all available services by the <listServicesByLocation> query, and then moves to a different location (while refreshing the service mappings), but without noticing the availability of other services. 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 list of services:

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.

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:

• clients continuously ask for the Service List, although it may not have changed
• 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 <listServicesByLocation>

The query <listServicesByLocation> may contain an additional <serviceListBoundaryRequest> element to additionally request the boundary for the service list based on the location provided, with the resulting location for the list to be presented either in a by value or by reference form. In the example below the value of the <serviceListBoundaryRequest> element is set to "value":

   <?xml version="1.0" encoding="UTF-8"?>
   <listServicesByLocation
      xmlns="urn:ietf:params:xml:ns:lost1"
      xmlns:gml="http://www.opengis.net/gml"
      xmlns:slb="urn:ietf:params:xml:schema:lost1:slb"
      recursive="true">
     <location id="5415203asdf548" profile="civic">
       <civicAddress xml:lang="en"
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>AT</country>
         <A1>Lower Austria</A1>
	 <A2>Bruck an der Leitha</A2>
         <A3>Wolfsthal</A3>
         <RD>Hauptplatz</RD>
         <HNO>1</HNO>
         <PC>2412</PC>
       </civicAddress>
     </location>
     <service>urn:service:sos</service>
     <slb:serviceListBoundaryRequest>
       value
     </slb:serviceListBoundaryRequest>
   </listServicesByLocation>

A possible response is shown below:

  <?xml version="1.0" encoding="UTF-8"?>
  <listServicesByLocationResponse
     xmlns="urn:ietf:params:xml:ns:lost1">
     xmlns:slb="urn:ietf:params:xml:schema:lost1:slb"
    <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="5415203asdf548"/>
    <slb:serviceListBoundary profile="civic">
      <civicAddress xml:lang="en"
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
        <country>AT</country>
        <A1>Lower Austria</A1>
      </civicAddress>
    </slb:serviceListBoundary>
  </listServicesByLocationResponse>

This response above indicates that the Service List is valid for Lower Austria. The <listServicesByLocation> request has to be repeated by the client 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 value of the <serviceListBoundaryRequest> element to "reference". Then the response contains a <serviceListBoundaryReference> element, as shown below.

   <?xml version="1.0" encoding="UTF-8"?>
   <listServicesByLocationResponse
      xmlns="urn:ietf:params:xml:ns:lost1">
      xmlns:slb="urn:ietf:params:xml:schema:lost1:slb"
     <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="5415203asdf548"/>
     <serviceListBoundaryReference
       source="authoritative.example"
       serviceListKey="123567890123567890123567890" />
   </listServicesByLocationResponse>

3.2.  Retrieving the <serviceListBoundary> via <getServiceListBoundary>

In order to retrieve the boundary corresponding a specific 'serviceListKey', the client issues a <getServiceListBoundary> request to the server identified in the 'source' attribute of the <serviceListBoundaryReference> element, similar to the <getServiceBoundary> request.

An example is shown below:

   <?xml version="1.0" encoding="UTF-8"?>
   <getServiceListBoundary xmlns="urn:ietf:params:xml:ns:lost1"
       serviceListKey="123567890123567890123567890"/>

The LoST server response is shown below:

   <?xml version="1.0" encoding="UTF-8"?>
   <getServiceListBoundaryResponse
      xmlns="urn:ietf:params:xml:schema:lost1:slb">
     <serviceListBoundary profile="civic"
        expires="2010-01-01T00:00:00Z">
       <civicAddress xml:lang="en"
          xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>AT</country>
         <A1>Lower Austria</A1>
       </civicAddress>
     </serviceListBoundary>
     <path>
       <via source="resolver.example"/>
       <via source="authoritative.example"/>
     </path>
   </getServiceListBoundaryResponse>

The 'serviceListKey' uniquely identifies a Service List Boundary as the 'key' does for the service boundary (see Section 5.6 in RFC 5222). Therefore the 'serviceListKey' is a random token with at least 128 bits of entropy and can be assumed globally unique. Whenever the boundary changes, a new 'serviceListKey' MUST be assigned.

Note: since LoST does not define an attribute to indicate which profile the clients understands in a <getServiceListBoundary> request, this document also does not define one for the <getServiceListBoundary> request.

3.3.  <serviceListBoundary>

The <serviceListBoundary> information that gets returned, indicates the geographic region in which all the service identifiers returned from a <serviceList> element are the same, within a <listServicesByLocation> query. A <serviceListBoundary> 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.

The server may return the boundary information in multiple profiles, but has to 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 <listServicesResponse>. <ListServices> requests are purely for diagnostic purposes and do not contain location information at all, so no boundary information is reasonable.

Also note that the <serviceListBoundary> 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 <serviceListBoundary> might be crucial to ensure that moving clients do not miss changes in the available services.

3.4.  Implementation Considerations

The subsections below discuss implementation issues for the LoST server and client for the serviceListBoundary support.

3.4.1.  Server Side

The mapping architecture and framework [RFC5582] (Schulzrinne, H., “Location-to-URL Mapping Architecture and Framework,” September 2009.) describes that each tree announces its coverage region (for one type of service, e.g. sos.police) to one or more forest guides. Forest guides peer with each other and synchronize their data. Hence, a forest guide has sufficient knowledge (it knows all the services and their coverage regions) to answer a <listServicesByLocation> query and additionally add the <serviceListBoundary> as well.

The calculation of the largest possible area for which the Service List stays the same might be a complex task. An alternative would be to return smaller areas that are easier to compute. In such a case some unneeded queries to the LoST server are the consequence, but still the main purpose of the <serviceListBoundary> is achieved: Never miss a change of available services. So a reasonable trade-off between the effort to generate the boundary information and the saved queries to the LoST server has to be considered.

Probably for some countries the county (or disrict, canton, state, ...) borders would be suitable as <serviceListBoundary>. Some neighbouring counties may have implemented different services while a <listServicesByLocation> query in other neighbouring counties still results in the same Service List. So when moving across a county border, it is at least ensured, that every device fetches a new Service List from the LoST server.

Other countries might have different structures and the generation of the <serviceListBoundary> might follow other rules as long as it is ensured that a client is able to notice any change in the Service List when moving.

3.4.2.  Client Side

A mobile client that already implements LoST and evaluates the <serviceBoundary> has almost everything that is needed to make use of the <serviceListBoundary>. Since the integration into LoST follows the concept of the <serviceBoundary> (and also makes use of the same location profiles), just the additional <serviceListBoundary> has to be evaluated. Whenever moving outside a <serviceListBoundary>, the client must perform a new <listServicesByLocation> query with the new location information in order to determine a change in available services.

4.  Security & Privacy Considerations

Security considerations for LoST are discussed in [RFC5222] (Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, “LoST: A Location-to-Service Translation Protocol,” August 2008.). This document extends LoST to also carry Service List Boundaries (and requests for them). These Service List Boundaries are calculated by the server based on the individual Service Boundaries and sent to clients in case the local policy allows this. Therefore it is generally considered to have the same level of sensitivity as for the Service Boundary and thus the same access control and confidentiality requirements as the base LoST protocol. As a result, the security measures incorporated in the base LoST specification provide sufficient protection for LoST messages that use the Service List Boundary extension.

5.  IANA Considerations

This document requests two actions by IANA: a XML schema registration and namespace registration, according to the description in the following sections.

5.1.  Relax NG Schema Registration

This document requests registration of the following Relax NG Schema to the IETF XML Registry [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.):

URI: urn:ietf:params:xml:schema:lost1:slb

Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (karlheinz.wolf@nic.at)

Relax NG Schema:

BEGIN

<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="urn:ietf:params:xml:ns:lost1"
   xmlns:slb="urn:ietf:params:xml:ns:lost1:slb">

  <include href="lost.rng">
  <!-- redefinition of LoST elements -->

    <start>
      <choice>
        <ref name="findService"/>
        <ref name="listServices"/>
        <ref name="listServicesByLocation"/>
        <ref name="getServiceBoundary"/>
        <ref name="findServiceResponse"/>
        <ref name="listServicesResponse"/>
        <ref name="listServicesByLocationResponse"/>
        <ref name="getServiceBoundaryResponse"/>
        <ref name="errors"/>
        <ref name="redirect"/>
        <ref name="slb:getServiceListBoundary"/>
        <ref name="slb:getServiceListBoundaryResponse"/>
      </choice>
    </start>

    <define name="listServicesByLocation">
      <element name="listServicesByLocation">
        <ref name="commonRequestPattern"/>
          <ref name="slb:serviceListBoundaryRequest"/>
      </element>
    </define>

    <define name="listServicesByLocationResponse">
      <element name="listServicesByLocationResponse">
        <ref name="serviceList"/>
        <ref name="commonResponsePattern"/>
        <ref name="locationUsed"/>
        <choice>
          <ref name="slb:serviceListBoundaryResponse"/>
          <ref name="slb:serviceListBoundaryReference"/>
        </choice>
      </element>
    </define>

  </include>

    <define name="serviceListBoundaryRequest">
      <element name="serviceListBoundary">
        <ref name="slb:serviceListBoundary"/>
        <choice>
          <value>value</value>
          <value>reference</value>
        </choice>
      </element>
    </define>

    <define name="serviceListBoundaryResponse">
      <element name="serviceListBoundary">
        <ref name="slb:serviceListBoundary"/>
        <attribute name="profile"/>
          <ref name="locationInformation"/>
      </element>
    </define>

    <define name="serviceListBoundaryReference">
      <element name="serviceListBoundaryReference">
        <ref name="slb:serviceListBoundaryReference"/>
        <attribute name="source"/>
        <attribute name="serviceListKey"/>
      </element>
    </define>

    <define name="getServiceListBoundary">
      <element name="getServiceListBoundary">
        <ref name="slb:getServiceListBoundary"/>
        <attribute name="serviceListKey"/>
      </element>
    </define>

    <define name="getServiceListBoundaryResponse">
      <element name="getServiceListBoundaryResponse">
        <ref name="slb:getServiceListBoundaryResponse"/>
        <attribute name="serviceListKey"/>
        <ref name="slb:serviceListBoundary"/>
        <ref name="path"/>
      </element>
    </define>

</grammar>
END

5.2.  Namespace Registration

This document requests registration of the following namespace (below the LoST namespace defined in [RFC5222] (Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, “LoST: A Location-to-Service Translation Protocol,” August 2008.)) to the IETF XML Registry [RFC3688] (Mealling, M., “The IETF XML Registry,” January 2004.):

URI: urn:ietf:params:xml:ns:lost1:slb

Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf (karlheinz.wolf@nic.at)

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 serviceListBoundary Namespace</title>
</head>
<body>
  <h1>Namespace for the LoST Service List Boundary</h1>
  <h2>urn:ietf:params:xml:ns:lost1:slb</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt">
   RFCXXXX</a>.</p>
</body>
</html>

END

6.  Acknowledgement

The author would like to thank Henning Schulzrinne for the discussion on the draft and Martin Thomson, Richard Barnes and Roger Marshall for their valuable input and text suggestions during the WGLC.

7.  References

7.1. Normative References

7.2. Informative References

Author's Address