ECRIT                                                            K. Wolf
Expires: May August 13, 2010                                   November                                February 9, 2009 2010

       Location-to-Service Translation Protocol (LoST) Extension:


   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 response from the LoST server 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 service list of services is valid. considered valid within.  Therefore,
   this document proposes a ServiceListBoundary <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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May August 13, 2010.

Copyright Notice
   Copyright (c) 2009 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
   ( 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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  LoST Extensions  . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Extensions to <ListServiceByLocation> <listServicesByLocation> . . . . . . . . . .  4
     3.2.  Retrieving the serviceList Boundary <serviceListBoundary> via
           getServiceListBoundary .
           <getServiceListBoundary> . . . . . . . . . . . . . . . . .  6
     3.3.  Service List Boundary  <serviceListBoundary>  . . . . . . . . . . . . . . . . . .  7
     3.4.  Implementation Considerations  . . . . . . . . . . . . . .  8
       3.4.1.  Server Side  . . . . . . . . . . . . . . . . . . . . .  8
       3.4.2.  Client Side  . . . . . . . . . . . . . . . . . . . . .  8  9

   4.  Security & Privacy Considerations  . . . . . . . . . . . . . .  9

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Relax NG Schema Registration . . . . . . . . . . . . . . .  9
     5.2.  Namespace Registration . . . . . . . . . . . . . . . . . . 11 12

   6.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 12

   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 12

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13

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] defines the ServiceBoundary, 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 Service List is valid.
   This may lead to the situation where a client initially discoveres 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

   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: list of services:


   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
   ServiceBoundary. 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, and client.
   Hence, the client is unable to recognize an emergency call to when the
   user enters the dialstring of the mountain rescue service will certainly
   fail. and thus the
   emergency call may fail altogether.

   Note that the ServiceBoundary Service Boundary (service region for an individual
   service) cannot be considered as an indicator for the region a
   specific service list Service List is valid for.  The service list Service List may even change
   within the ServiceBoundary 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 ask for the service list, Service List, although it may not
      have changed
   o  a boundary information (telling the client that the service list Service List
      does not change inside this area)

   Since the LoST protocol has employs the ServiceBoundary Service Boundary concept in order
   to avoid that having clients continuously try trying to refresh the mapping of
   a specific service, a ServiceListBoundary Service List Boundary mechanism would provide a
   mechanism advantages for service lists. Service Lists.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 <serviceListBoundary> in a
   similar way as the ServiceBoundary. <serviceBoundary>.

3.1.  Extensions to <ListServiceByLocation> <listServicesByLocation>

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

   <?xml version="1.0" encoding="UTF-8"?>
     <location id="mylocation" id="5415203asdf548" profile="civic">
       <civicAddress xml:lang="en"
         <A1>Lower Austria</A1>
         <A2>Bruck an der Leitha</A2>

   A possible response is shown below:

     <?xml version="1.0" encoding="UTF-8"?>
       <serviceList expires="2010-01-01T00:00:00Z">
         <via source="resolver.example"/>
         <via source="authoritative.example"/>
       <locationUsed id="mylocation"/> id="5415203asdf548"/>
       <slb:serviceListBoundary profile="civic">
         <civicAddress xml:lang="en"
           <A1>Lower Austria</A1>


   This response above indicates that the service list 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 Service List becomes invalid.

   The boundary can also be requested by reference when setting the
   attribute serviceListBoundary
   value of the <serviceListBoundaryRequest> element to "reference".
   Then the response contains a serviceListBoundaryReference <serviceListBoundaryReference> element,
   as shown below.

      <?xml version="1.0" encoding="UTF-8"?>
        <serviceList expires="2010-01-01T00:00:00Z">

          <via source="resolver.example"/>
          <via source="authoritative.example"/>
        <locationUsed id="mylocation"/> id="5415203asdf548"/>
          serviceListKey="123567890123567890123567890" />

3.2.  Retrieving the serviceList Boundary <serviceListBoundary> via getServiceListBoundary <getServiceListBoundary>

   In order to retrieve the boundary corresponding a specific
   'serviceListKey', the client issues a <getServiceListBoundary> request,
   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"

   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"
         <A1>Lower Austria</A1>
       <via source="resolver.example"/>
       <via source="authoritative.example"/>

   The serviceListKey 'serviceListKey' uniquely identifies a serviceListBoundary Service List Boundary as
   key 'key' does for the service boundary (see Section 5.6 in RFC
   5222).  Therefore the serviceListKey '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 'serviceListKey' MUST be

   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.  Service List Boundary  <serviceListBoundary>

   The service list boundary <serviceListBoundary> information that gets returned, indicates a
   the geographic region within in which all
   <listServicesByLocation> queries with the same service identifiers
   result in returned
   from a <serviceList> element are the same serviceList. same, within a
   <listServicesByLocation> query.  A service list boundary <serviceListBoundary> may consist
   of geometric shapes (both in civic and geodetic location format), and
   may be non-contiguous, like the service boundary. Service Boundary.

   The mapping of the specific services within the service list boundary 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 <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. Service Boundary.  However, especially for
   emergency services, the serviceListBoundary <serviceListBoundary> might be crucial to
   ensure that moving clients do not miss changes in the available

3.4.  Implementation Considerations

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

3.4.1.  Server Side

   The mapping architecture and framework [RFC5582] 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 <listServicesByLocation> query and additionally
   add the serviceListBoundary <serviceListBoundary> as well.

   The calculation of the largest possible area for which the service
   list 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 <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. <serviceListBoundary>.  Some
   neighbouring counties may have implemented different services while a
   <listServicesByLocation> query in other neighbouring counties still
   results in the same serviceList. Service List.  So when moving across a county
   border, it is at least ensured, that every device fetches a new
   service list
   Service List from the LoST server.

   Other countries might have different structures and the generation of
   the serviceListBoundary <serviceListBoundary> might follow other rules as long as it is
   ensured that a client is able to notice any change in the service
   list 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. <serviceListBoundary>.  Since the integration into LoST follows
   the concept of the serviceBoundary <serviceBoundary> (and also makes use of the same
   location profiles), just the additional serviceListBoundary <serviceListBoundary> has to
   be evaluated.  Whenever moving outside a serviceListBoundary, <serviceListBoundary>, the
   client must perform a new listServicesByLocation <listServicesByLocation> query with the new
   location information in order to determine a change in available

4.  Security & Privacy Considerations

   Security considerations for LoST are discussed in [RFC5222]. RFC5222.  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]:

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

   Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf
   Relax NG Schema:


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

     <div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">
           Allows requesting the serviceListBoundary by reference or by value
         </a:documentation> xmlns="urn:ietf:params:xml:ns:lost1"

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

           <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"/>

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

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

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

     <div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">
           Returns the serviceListBoundary by Reference

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

     <div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">
           Returns the serviceListBoundary by Value

       <define name="serviceListBoundary"> name="serviceListBoundaryReference">
         <element name="serviceListBoundary"> name="serviceListBoundaryReference">
           <ref name="slb:serviceListBoundary"/> name="slb:serviceListBoundaryReference"/>
           <attribute name="profile"/>
                   <ref name="ls:locationInformation"/> name="source"/>
           <attribute name="serviceListKey"/>


     <div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">

           Request for the serviceListBoundary

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


     <div xmlns:slb="urn:ietf:params:xml:schema:lost1:slb">

           Response to getServiceListBoundary

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



5.2.  Namespace Registration

   This document requests registration of the following namespace (below
   the LoST namespace defined in [RFC5222]) to the IETF XML Registry

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

   Registrant Contact: IETF ECRIT Working Group, Karl Heinz Wolf



   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
   <html xmlns="">
     <meta http-equiv="content-type"
     <title>LoST serviceListBoundary Namespace</title>
     <h1>Namespace for the LoST serviceListBoundary</h1> Service List Boundary</h1>
   <p>See <a href="">


6.  Acknowledgement

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

7.  Normative References

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, August 2008.

   [RFC5582]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
              Framework", RFC 5582, September 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

Author's Address

   Karl Heinz Wolf GmbH
   Karlsplatz 1/2/9
   Wien  A-1010

   Phone: +43 1 5056416 37