tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5222

 Errata 
Proposed STD
Pages: 69
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ECRIT

LoST: A Location-to-Service Translation Protocol

Part 1 of 3, p. 1 to 19
None       Next RFC Part

Updated by:    6848


Top       ToC       Page 1 
Network Working Group                                          T. Hardie
Request for Comments: 5222                                Qualcomm, Inc.
Category: Standards Track                                      A. Newton
                                  American Registry for Internet Numbers
                                                          H. Schulzrinne
                                                     Columbia University
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                             August 2008


            LoST: A Location-to-Service Translation Protocol

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes an XML-based protocol for mapping service
   identifiers and geodetic or civic location information to service
   contact URIs.  In particular, it can be used to determine the
   location-appropriate Public Safety Answering Point (PSAP) for
   emergency services.

Table of Contents

 1.  Introduction .................................................. 3
 2.  Terminology and Requirements Notation ......................... 4
 3.  Overview of Protocol Usage .................................... 5
 4.  LoST Servers and Their Resolution  ............................ 6
 5.  The <mapping> Element  ........................................ 7
   5.1.  The Mapping Data Source: 'source', 'sourceId', and
         'lastUpdated' Attributes .................................. 7
   5.2.  Mapping Validity:  The 'expires' Attribute ................ 8
   5.3.  Describing the Service with the <displayName> Element  .... 8
   5.4.  The Mapped Service: The <service> Element ................. 8
   5.5.  Defining the Service Region with the <serviceBoundary>
         Element  .................................................. 9
   5.6.  Service Boundaries by Reference: The
         <serviceBoundaryReference> Element ........................ 9
   5.7.  The Service Number: The <serviceNumber> Element  ......... 10
   5.8.  Service URLs: The <uri> Element  ......................... 10

Top      ToC       Page 2 
 6.  Path of a Request: The <path> Element  ....................... 10
 7.  Identifying the Location Element Used for Mapping:
     <locationUsed> ............................................... 11
 8.  Mapping a Location and Service to URLs: <findService>  ....... 11
   8.1.  Overview ................................................. 11
   8.2.  Examples ................................................. 11
     8.2.1.  Example Using Geodetic Coordinates ................... 11
     8.2.2.  Civic Address Mapping Example  ....................... 13
   8.3.  Components of the <findService> Request  ................. 15
     8.3.1.  The <location> Element ............................... 15
     8.3.2.  Identifying the Service:  The <service> Element  ..... 16
     8.3.3.  Recursion and Iteration  ............................. 16
     8.3.4.  Service Boundary ..................................... 16
     8.3.5.  Requesting Civic Location Validation ................. 16
   8.4.  Components of the Mapping Response
         <findServiceResponse>  ................................... 18
     8.4.1.  Overview ............................................. 18
     8.4.2.  Civic Address Validation: The <locationValidation>
             Element  ............................................. 19
 9.  Retrieving the Service Boundary via <getServiceBoundary> ..... 19
 10. List Services: <listServices>  ............................... 21
 11. List Services By Location: <listServicesByLocation>  ......... 22
 12. Location Profiles  ........................................... 24
   12.1. Location Profile Usage ................................... 25
   12.2. Two-Dimensional Geodetic Profile ......................... 30
   12.3. Basic Civic Profile  ..................................... 31
 13. Errors, Warnings, and Redirects  ............................. 32
   13.1. Errors ................................................... 32
   13.2. Warnings ................................................. 34
   13.3. Redirects  ............................................... 36
 14. LoST Transport: HTTP ......................................... 36
 15. Relax NG Schema  ............................................. 37
 16. Internationalization Considerations  ......................... 44
 17. IANA Considerations  ......................................... 44
   17.1. U-NAPTR Registrations  ................................... 44
   17.2. Content-Type Registration for 'application/lost+xml' ..... 44
   17.3. LoST Relax NG Schema Registration  ....................... 46
   17.4. LoST Namespace Registration  ............................. 46
   17.5. LoST Location Profile Registry ........................... 47
 18. Security Considerations  ..................................... 47
 19. Acknowledgments  ............................................. 48
 20. References ................................................... 51
   20.1. Normative References ..................................... 51
   20.2. Informative References ................................... 52
 Appendix A.  Non-Normative RELAX NG Schema in XML Syntax ......... 54
 Appendix B.  Examples Online ..................................... 67

Top      ToC       Page 3 
1.  Introduction

   Protocols such as Naming Authority Pointer (NAPTR) records and the
   Service Location Protocol (SLP) can be used to discover servers
   offering a particular service.  However, for an important class of
   services the appropriate specific service instance depends both on
   the identity of the service and the geographic location of the entity
   that needs to reach it.  Emergency telecommunications services are an
   important example; here, the service instance is a Public Safety
   Answering Point (PSAP) that has jurisdiction over the location of the
   user making the call.  The desired PSAP isn't necessarily the one
   that is topologically or even line-of-sight closest to the caller;
   rather, it is the one that serves the caller's location based on
   jurisdictional boundaries.

   This document describes a protocol for mapping a service identifier
   and location information compatible with the Presence Information
   Data Format Location Object (PIDF-LO) [6] to one or more service
   URIs.  Service identifiers take the form of the service URNs
   described in [9].  Location information here includes revised civic
   location information [10] and a subset of the PIDF-LO profile [13],
   which consequently includes the Geo-Shapes [12] defined for GML [11].
   Example service URI schemes include sip [14], xmpp [15], and tel
   [16].  While the initial focus is on providing mapping functions for
   emergency services, it is likely that the protocol is applicable to
   other service URNs.  For example, in the United States, the "2-1-1"
   and "3-1-1" service numbers follow a similar location-to-service
   behavior as emergency services.

   This document names this protocol "LoST", for Location-to-Service
   Translation.  LoST satisfies the requirements [18] for mapping
   protocols.  LoST provides a number of operations, centered around
   mapping locations and service URNs to service URLs and associated
   information.  LoST mapping queries can contain either civic or
   geodetic location information.  For civic addresses, LoST can
   indicate which parts of the civic address are known to be valid or
   invalid, thus providing address validation, as described in Section
   3.5 of [18].  LoST indicates errors in the location data to
   facilitate debugging and proper user feedback, but also provides
   best-effort answers.

   LoST queries can be resolved recursively or iteratively.  To minimize
   round trips and to provide robustness against network failures, LoST
   supports caching of individual mappings and indicates the region for
   which the same answer would be returned ("service region").

Top      ToC       Page 4 
   As defined in this document, LoST messages are carried in HTTP and
   HTTPS protocol exchanges, facilitating use of TLS for protecting the
   integrity and confidentiality of requests and responses.

   This document focuses on the description of the protocol between the
   mapping client and the mapping server.  Other functions, such as
   discovery of mapping servers, data replication and the overall
   mapping server architecture are described in a separate document
   [19].

   The query message carries location information and a service
   identifier encoded as a Uniform Resource Name (URN) (see [9]) from
   the LoST client to the LoST server.  The LoST server uses its
   database to map the input values to one or more Uniform Resource
   Identifiers (URIs) and returns those URIs along with optional
   information, such as hints about the service boundary, in a response
   message to the LoST client.  If the server cannot resolve the query
   itself, it may in turn query another server or return the address of
   another LoST server, identified by a LoST server name.  In addition
   to the mapping function described in Section 8, the protocol also
   allows to retrieve the service boundary (see Section 9) and to list
   the services available for a particular location (see Section 11) or
   supported by a particular server (see Section 10).

2.  Terminology and Requirements Notation

   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 [1].

   This document uses the following terms:

   Mapping:
      Mapping is a process that takes a location and a service
      identifier as inputs and returns one or more URIs.  Those URIs can
      point either to a host providing that service or to a host that in
      turn routes the request to the final destination.  This definition
      is a generalization of the term "mapping" as used in [18], because
      LoST can be used for non-emergency services.

   LoST client:
      A host acts as a LoST client if it sends LoST query messages and
      receives LoST response messages.

   LoST server:
      A host acts as a LoST server if it receives LoST query messages
      and sends LoST response messages.  In recursive operation, the
      same entity may be both a client and a server.

Top      ToC       Page 5 
   Authoritative LoST server:
      An authoritative server acts only as a server and successfully
      resolves the input location and service identifier to a URI or set
      of URIs.

   Service boundary:
      A service boundary circumscribes the region within which all
      locations map to the same service URI or set of URIs for a given
      service.  A service boundary may consist of several non-contiguous
      geometric shapes.

   Validation:
      The term "validation" describes the behavior defined as "location
      validation" in Section 3.5 of [18].

   Additional emergency service terminology can be found in [18].

3.  Overview of Protocol Usage

   The LoST protocol supports the following types of queries and
   responses:

   <findService> and <findServiceResponse>
      A LoST client retrieves contact URIs based on location information
      and a service identifier with this request and response.  The same
      query type may also ask for location validation and for service
      numbers, either combined with a mapping request or separately.
      The details can be found in Section 8.

   <getServiceBoundary> and <getServiceBoundaryResponse>
      A LoST client obtains a service boundary with this request and
      response, as described in Section 9.

   <listServices> and <listServicesResponse>
      With this request and response, a LoST client can find out which
      services a LoST server supports, as described in Section 10.

   <listServicesByLocation> and <listServicesByLocationResponse>
      A LoST client can determine with this request and response which
      services are available for a specific location region.  Section 11
      describes the details.

   LoST clients may initiate any of the above queries at any time.
   Among the common triggers are:

   1.  when the client initially starts up or attaches to a network;

Top      ToC       Page 6 
   2.  when the client detects that its location has changed
       sufficiently that it is outside the bounds of the service region;

   3.  when a SIP message arrives at a SIP proxy performing location-
       based call routing;

   4.  when cached mapping information has expired; and

   5.  when invoking a particular service.  At that time, a client may
       omit requests for service boundaries or other auxiliary
       information.

   A service-specific Best Current Practice (BCP) document, such as
   [21], governs whether a client is expected to invoke the mapping
   service just before needing the service or whether to rely on cached
   answers.  Cache entries expire at their expiration time (see
   Section 5.2), or they become invalid if the caller's device moves
   beyond the boundaries of the service region.  Service-specific Best
   Current Practice documents may also provide guidance on the contact
   URI schemes most appropriate to the service.  As a general set of
   guidelines, URI schemes that do not provide mechanisms for actually
   initiating a contact method should be avoided (examples include data,
   info, cid, and tag) as transforming those references into contact
   mechanisms requires a layer of indirection that makes the overall
   mechanism more fragile.  Provisionally registered URI schemes should
   also be carefully considered before use, because they are subject to
   change in core semantics.

4.  LoST Servers and Their Resolution

   LoST servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/
   Dynamic Delegation Discovery Service) [8] application unique strings,
   in the form of a DNS name.  An example is 'lostserver.example.com'.

   Clients need to use the U-NAPTR [8] specification described below to
   obtain a URI (indicating host and protocol) for the applicable LoST
   service.  In this document, only the HTTP and HTTPS URL schemes are
   defined.  Note that the HTTP URL can be any valid HTTP URL, including
   those containing path elements.

   The following two DNS entries show the U-NAPTR resolution for
   "example.com" to the HTTPS URL https://lostserv.example.com/secure or
   the HTTP URL http://lostserver.example.com, with the former being
   preferred.

Top      ToC       Page 7 
       example.com.

       IN NAPTR 100  10   "u"    "LoST:https"
            "!.*!https://lostserver.example.com/secure!"  ""

       IN NAPTR 200  10   "u"    "LoST:http"
            "!.*!http://lostserver.example.com!"  ""

   Clients learn the LoST server's host name by means beyond the scope
   of this specification, such as SIP configuration and DHCP [25].

5.  The <mapping> Element

   The <mapping> element is the core data element in LoST, describing a
   service region and the associated service URLs.  Its attributes and
   elements are described in subsections below.

5.1.  The Mapping Data Source: 'source', 'sourceId', and 'lastUpdated'
      Attributes

   The 'source', 'sourceId', and 'lastUpdated' attributes uniquely
   identify a particular mapping record.  They are created by the
   authoritative source for a mapping and are never modified when a
   mapping is served from a cache.  All three attributes are REQUIRED
   for all <mapping> elements.  A receiver can replace a mapping with
   another one having the same 'source' and 'sourceId' and a more recent
   time in 'lastUpdated'.

   The 'source' attribute contains a LoST application unique string
   identifying the authoritative generator of the mapping (Section 4).

   The 'sourceId' attribute identifies a particular mapping and contains
   an opaque token that MUST be unique among all different mappings
   maintained by the authoritative source for that particular service.
   For example, a Universally Unique Identifier (UUID) is a suitable
   format.

   The 'lastUpdated' attribute describes when a specific instance of
   mapping, identified by the combination of 'source' and 'sourceId',
   was last changed.  The contents of this attribute has the XML data
   type dateTime in its timezoned form, using the canonical UTC
   representation with the letter 'Z' as the timezone indicator.

Top      ToC       Page 8 
5.2.  Mapping Validity:  The 'expires' Attribute

   The 'expires' attribute contains the absolute time at which the
   mapping becomes invalid.  The contents of this attribute is a
   timezoned XML type dateTime, in canonical representation.  The
   <mapping> element MUST include the 'expires' attribute.

   Optionally, this attribute may contain the values of 'NO-CACHE' and
   'NO-EXPIRATION' instead of a dateTime value.  The value 'NO-CACHE' is
   an indication that the mapping should not be cached.  The value of
   'NO-EXPIRATION' is an indication that the mapping does not expire.

   On occasion, a server may be forced to return an expired mapping if
   it cannot reach the authoritative server or the server fails to
   return a usable answer.  Clients and servers MAY cache the mapping so
   that they have at least some information available.  Caching servers
   that have such stale information SHOULD re-attempt the query each
   time a client requests a mapping.  Since the expired mapping will be
   returned to the client as a non-error/non-warning response, the
   client MUST check the 'expires' attribute; if the mapping has
   expired, local policy at the client determines whether it discards
   the answer and tries again later or uses the possibly stale response.

5.3.  Describing the Service with the <displayName> Element

   Zero or more <displayName> elements describe the service with a
   string that is suitable for display to human users, each annotated
   with the 'xml:lang' attribute that contains a language tag to aid in
   the rendering of text.

5.4.  The Mapped Service: The <service> Element

   The mandatory <service> element identifies the service for which this
   mapping applies.  Two cases need to be distinguished when the LoST
   server sets the <service> element in the response message:

   1.  If the requested service, identified by the service URN [9] in
       the <service> element of the request, exists for the location
       indicated, then the LoST server copies the service URN from the
       request into the <service> element.

   2.  If, however, the requested service, identified by the service URN
       [9] in the <service> element in the request, does not exist for
       the location indicated, the server either can return a
       <serviceNotImplemented> (Section 13.1) error or can provide an
       alternate service that approximates the desired service for that

Top      ToC       Page 9 
       location.  In the latter case, the server MUST include a
       <service> element with the alternative service URN.  The choice
       of service URN is left to local policy, but the alternate service
       should be able to satisfy the original service request.

5.5.  Defining the Service Region with the <serviceBoundary> Element

   A response MAY indicate the region for which the service URL returned
   would be the same as in the actual query, the so-called service
   region.  The service region can be indicated by value or by reference
   (see Section 5.6).  If a client moves outside the service area and
   wishes to obtain current service data, it sends a new query with its
   current location.  The service region is described by value in one or
   more <serviceBoundary> elements, each formatted according to a
   specific location profile, identified by the 'profile' attribute (see
   Section 12). <serviceBoundary> elements formatted according to
   different location profiles are alternative representations of the
   same area, not additive to one another; this allows a client
   understanding only one of the profile types to be sure it has a
   complete view of the serviceBoundary.  Within a serviceBoundary
   element there may, however, be multiple locations which are additive;
   this is necessary because some <serviceBoundary> areas could not be
   easily expressed with a single shape or civic location.  If included
   in a response, the <serviceBoundary> element MUST contain at least
   one service boundary that uses the same profile as the request.

   A service boundary is requested by the client, using the
   'serviceBoundary' attribute in the request with the value set to
   "value".

5.6.  Service Boundaries by Reference: The <serviceBoundaryReference>
      Element

   Since geodetic service boundaries may contain thousands of points and
   can thus be quite large, clients may wish to conserve bandwidth by
   requesting a reference to the service boundary instead of the value
   described in Section 5.5.  The identifier of the service boundary is
   returned as an attribute of the <serviceBoundaryReference> element,
   along with a LoST application unique string (see Section 4)
   identifying the server from where it can be retrieved.  The actual
   value of the service boundary is then retrieved with the
   getServiceBoundary (Section 9) request.

   A reference to a service boundary is requested by the client using
   the 'serviceBoundary' attribute in the request with the value set to
   "reference".  A LoST server may decide, based on local policy, to
   return the service boundary by value or to omit the
   <serviceBoundaryReference> element in the response.

Top      ToC       Page 10 
   The identifier is a random token with at least 128 bits of entropy
   and can be assumed to be globally unique.  It uniquely references a
   particular boundary.  If the boundary changes, a new identifier MUST
   be chosen.  Because of these properties, a client receiving a mapping
   response can simply check if it already has a copy of the boundary
   with that identifier.  If so, it can skip checking with the server
   whether the boundary has been updated.  Since service boundaries are
   likely to remain unchanged for extended periods of time, possibly
   exceeding the normal lifetime of the service URL, this approach
   avoids unnecessarily refreshing the boundary information just because
   the remainder of the mapping has become invalid.

5.7.  The Service Number: The <serviceNumber> Element

   The service number is returned in the optional <serviceNumber>
   element.  It contains a string of digits, * and # that a user on a
   device with a 12-key dial pad could use to reach that particular
   service.

5.8.  Service URLs: The <uri> Element

   The response returns the service URLs in one or more <uri> elements.
   The URLs MUST be absolute URLs.  The ordering of the URLs has no
   particular significance.  Each URL scheme MUST only appear at most
   once, but it is permissible to include both secured and regular
   versions of a protocol, such as both 'http' and 'https' or 'sip' and
   'sips'.

6.  Path of a Request: The <path> Element

   To prevent loops and to allow tracing of request and response paths,
   all requests that allow recursion include a <path> element that
   contains one or more <via> elements, each possessing an attribute
   containing a LoST application unique string (see Section 4).  The
   order of <via> elements corresponds to the order of LoST servers,
   i.e., the first <via> element identifies the server that initially
   received the request from the client issuing the request.  Every
   server in a recursive query operation is included in the <path>
   element, including the first server to receive it.

   The server that answers the request instead of forwarding it, such as
   the authoritative server, copies the <path> element verbatim into the
   response.  The <path> element is not modified in responses as the
   responses traverses the server chain back to the querying client.

   If a query is answered iteratively, the querier includes all servers
   that it has already contacted.

Top      ToC       Page 11 
   When a cached mapping is returned, then the <path> element cached
   together with the mapping is returned.

   The example in Figure 4 indicates that the answer was given to the
   client by the LoST server at esgw.ueber-110.de.example, which got the
   answer from the (authoritative) LoST server at
   polizei.muenchen.de.example.

7.  Identifying the Location Element Used for Mapping: <locationUsed>

   Several of the requests can provide one or more <location> elements,
   among which the server gets to choose.  It is useful for the client
   to be able to determine which one was actually used in producing the
   result.  For that purpose, the <location> tag MUST contain an 'id'
   attribute that uniquely identifies the <location> element.  The
   format of the identifier is left to the client; it could, for
   example, use a hash of the location information.  The server returns
   the identifier for the <location> element it used in the
   <locationUsed> tag.

8.  Mapping a Location and Service to URLs: <findService>

8.1.  Overview

   The <findService> query constitutes the core of the LoST
   functionality, mapping civic or geodetic locations to URLs and
   associated data.  After giving an example, we enumerate the elements
   of the query and response.

8.2.  Examples

8.2.1.  Example Using Geodetic Coordinates

   The following is an example of mapping a service to a location using
   geodetic coordinates, for the service associated with the police
   (urn:service:sos.police).

Top      ToC       Page 12 
   <?xml version="1.0" encoding="UTF-8"?>
   <findService
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"
     serviceBoundary="value"
     recursive="true">

     <location id="6020688f1ce1896d" profile="geodetic-2d">
       <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
          <p2:pos>37.775 -122.422</p2:pos>
       </p2:Point>
     </location>
     <service>urn:service:sos.police</service>

   </findService>

                 Figure 1: A <findService> geodetic query

   Given the query above, a server would respond with a service, and
   information related to that service.  In the example below, the
   server has mapped the location given by the client for a police
   service to the New York City Police Department, instructing the
   client that it may contact them via the URIs "sip:nypd@example.com"
   and "xmpp:nypd@example.com".  The server has also given the client a
   geodetic, two-dimensional boundary for this service.  The mapping was
   last updated on November 1, 2006 and expires on January 1, 2007.  If
   the client's location changes beyond the given service boundary or
   the expiration time has been reached, it may want to requery for this
   information, depending on the usage environment of LoST.

Top      ToC       Page 13 
   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml">
     <mapping
       expires="2007-01-01T01:44:33Z"
       lastUpdated="2006-11-01T01:00:00Z"
       source="authoritative.example"
       sourceId="7e3f40b098c711dbb6060800200c9a66">
       <displayName xml:lang="en">
         New York City Police Department
       </displayName>
       <service>urn:service:sos.police</service>
       <serviceBoundary profile="geodetic-2d">
         <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
           <p2:exterior>
             <p2:LinearRing>
               <p2:pos>37.775 -122.4194</p2:pos>
               <p2:pos>37.555 -122.4194</p2:pos>
               <p2:pos>37.555 -122.4264</p2:pos>
               <p2:pos>37.775 -122.4264</p2:pos>
               <p2:pos>37.775 -122.4194</p2:pos>
             </p2:LinearRing>
           </p2:exterior>
         </p2:Polygon>
       </serviceBoundary>
       <uri>sip:nypd@example.com</uri>
       <uri>xmpp:nypd@example.com</uri>
       <serviceNumber>911</serviceNumber>
     </mapping>
     <path>
       <via source="resolver.example"/>
       <via source="authoritative.example"/>
     </path>
     <locationUsed id="6020688f1ce1896d"/>
   </findServiceResponse>

             Figure 2: A <findServiceResponse> geodetic answer

8.2.2.  Civic Address Mapping Example

   The example below shows how to map a service to a location much like
   the example in Section 8.2.1, but using civic address location
   information.  In this example, the client requests the service
   associated with police (urn:service:sos.police) along with a specific
   civic address (house number 6 on a street named Otto-Hahn-Ring in
   Munich, Germany).

Top      ToC       Page 14 
   <?xml version="1.0" encoding="UTF-8"?>
   <findService xmlns="urn:ietf:params:xml:ns:lost1"
     recursive="true" serviceBoundary="value">
     <location id="627b8bf819d0bad4d" profile="civic">
       <civicAddress
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>DE</country>
         <A1>Bavaria</A1>
         <A3>Munich</A3>
         <A6>Otto-Hahn-Ring</A6>
         <HNO>6</HNO>
         <PC>81675</PC>
       </civicAddress>
     </location>
     <service>urn:service:sos.police</service>
   </findService>

               Figure 3: A <findService> civic address query

   Given the query above, a server would respond with a service, and
   information related to that service.  In the example below, the
   server has mapped the location given by the client for a police
   service to the Muenchen Polizei-Abteilung, instructing the client
   that it may contact them via the URIs sip:munich-police@example.com
   and xmpp:munich-police@example.com.  The server has also given the
   client a civic address boundary (the city of Munich) for this
   service.  The mapping was last updated on November 1, 2006 by the
   authoritative source "polizei.muenchen.de.example" and expires on
   January 1, 2007.  This instructs the client to requery for the
   information if its location changes beyond the given service boundary
   (i.e., beyond the indicated district of Munich) or after January 1,
   2007.

Top      ToC       Page 15 
    <?xml version="1.0" encoding="UTF-8"?>
    <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
      <mapping
        expires="2007-01-01T01:44:33Z"
        lastUpdated="2006-11-01T01:00:00Z"
        source="esgw.ueber-110.de.example"
        sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
        <displayName xml:lang="de">
          Muenchen Polizei-Abteilung
        </displayName>
        <service>urn:service:sos.police</service>
        <serviceBoundary
          profile="civic">
          <civicAddress
            xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
            <country>DE</country>
            <A1>Bavaria</A1>
            <A3>Munich</A3>
            <PC>81675</PC>
          </civicAddress>
        </serviceBoundary>
        <uri>sip:munich-police@example.com</uri>
        <uri>xmpp:munich-police@example.com</uri>
        <serviceNumber>110</serviceNumber>
      </mapping>
      <path>
        <via source="esgw.ueber-110.de.example"/>
        <via source="polizei.muenchen.de.example"/>
      </path>
      <locationUsed id="627b8bf819d0bad4d"/>
    </findServiceResponse>

          Figure 4: A <findServiceResponse> civic address answer

8.3.  Components of the <findService> Request

   The <findService> request includes attributes and elements that
   govern whether the request is handled iteratively or recursively,
   whether location validation is performed, and which elements may be
   contained in the response.

8.3.1.  The <location> Element

   The <findService> query communicates location information using one
   or more <location> elements, which MUST conform to a location profile
   (see Section 12).  There MUST NOT be more than one location element

Top      ToC       Page 16 
   for each distinct location profile.  The order of location elements
   is significant; the server uses the first location element where it
   understands the location profile.

8.3.2.  Identifying the Service:  The <service> Element

   The type of service desired is specified by the <service> element.
   It contains service URNs from the registry established in [9].

8.3.3.  Recursion and Iteration

   LoST can operate in either recursive or iterative mode, on a request-
   by-request basis.  In recursive mode, the LoST server initiates
   queries on behalf of the requester and returns the result to the
   requester.

   In iterative mode, the server contacted returns a redirection
   response indicating the next server to be queried if the server
   contacted cannot provide an answer itself.

   For the queries defined in this document, only the LoST <findService>
   and <listServicesByLocation> queries can be recursive, as indicated
   by the 'recursive' attribute.  A value of "true" indicates a
   recursive query, with the default being "false" when the attribute is
   omitted.  Regardless of the attribute, a server MAY always answer a
   query by providing a LoST application unique string (see Section 4),
   i.e., indirection; however, it MUST NOT recurse if the attribute is
   "false".

8.3.4.  Service Boundary

   LoST <mapping> elements can describe the service boundary either by
   value or by reference.  Returning a service boundary reference is
   generally more space-efficient for geospatial (polygon) boundaries
   and if the boundaries change rarely, but does incur an additional
   <getServiceBoundary> request.  The querier can express a preference
   for one or the other modality with the 'serviceBoundary' attribute in
   the <findService> request, but the server makes the final decision as
   to whether to return a reference or a value.

8.3.5.  Requesting Civic Location Validation

   Civic address validation is requested by setting the optional
   attribute 'validateLocation' to true.  If the attribute is omitted,
   it is assumed to be false.  The response is described in
   Section 8.4.2.  The example in Figure 5 demonstrates address
   validation.  If the server chooses a geodetic location among the
   locations provided in a request, the attribute is ignored.

Top      ToC       Page 17 
   <?xml version="1.0" encoding="UTF-8"?>
   <findService
     xmlns="urn:ietf:params:xml:ns:lost1"
     recursive="true"
     validateLocation="true"
     serviceBoundary="value">
     <location id="627b8bf819d0bad4d" profile="civic">
       <civicAddress
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>DE</country>
         <A1>Bavaria</A1>
         <A3>Munich</A3>
         <A6>Otto-Hahn-Ring</A6>
         <HNO>6</HNO>
         <PC>81675</PC>
       </civicAddress>
     </location>
     <service>urn:service:sos.police</service>
   </findService>

      Figure 5: A <findService> query with address validation request

Top      ToC       Page 18 
   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
     <mapping
       expires="2007-01-01T01:44:33Z"
       lastUpdated="2006-11-01T01:00:00Z"
       source="authoritative.example"
       sourceId="4db898df52b84edfa9b6445ea8a0328e">
       <displayName xml:lang="de">
         Muenchen Polizei-Abteilung
       </displayName>
       <service>urn:service:sos.police</service>
       <serviceBoundary profile="civic">
         <civicAddress
           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
           <country>DE</country>
           <A1>Bavaria</A1>
           <A3>Munich</A3>
           <PC>81675</PC>
         </civicAddress>
       </serviceBoundary>
       <uri>sip:munich-police@example.com</uri>
       <uri>xmpp:munich-police@example.com</uri>
       <serviceNumber>110</serviceNumber>
     </mapping>
     <locationValidation>
       <valid>country A1 A3 A6</valid>
       <invalid>PC</invalid>
       <unchecked>HNO</unchecked>
     </locationValidation>
     <path>
       <via source="resolver.example"/>
       <via source="authoritative.example"/>
     </path>
     <locationUsed id="627b8bf819d0bad4d"/>
   </findServiceResponse>

     Figure 6: A <findServiceResponse> message with address validation
                                information

8.4.  Components of the Mapping Response <findServiceResponse>

8.4.1.  Overview

   Mapping responses consist of the <mapping> element (Section 5)
   describing the mapping itself, possibly followed by warnings
   (Section 13.2), location validation information (Section 8.4.2), and
   an indication of the path (Section 6) the response has taken.

Top      ToC       Page 19 
8.4.2.  Civic Address Validation: The <locationValidation> Element

   A server can indicate in its response which civic address elements it
   has recognized as valid, which ones it has ignored, and which ones it
   has checked and found to be invalid.  The server SHOULD include this
   information if the 'validateLocation' attribute in the request was
   true, but local policy at the server may allow this information to be
   omitted.  Each element contains a list of tokens separated by
   whitespace, enumerating the civic location labels used in child
   elements of the <civicAddress> element.  The <valid> element
   enumerates those civic address elements that have been recognized as
   valid by the LoST server and that have been used to determine the
   mapping.  The <unchecked> elements enumerates the civic address
   elements that the server did not check and that were not used in
   determining the response.  The <invalid> element enumerate civic
   address elements that the server attempted to check, but that did not
   match the other civic address elements found in the <valid> list.
   Civic location tokens that are not listed in either the <valid>,
   <invalid>, or <unchecked> element belong to the class of unchecked
   tokens.

   Note that the same address can yield different responses if parts of
   the civic address contradict each other.  For example, if the postal
   code does not match the city, local server policy determines whether
   the postal code or the city is considered valid.  The mapping
   naturally corresponds to the valid elements.

   The example shown in Figure 5 and in Figure 6 indicates that the
   tokens 'country', 'A1', 'A3', and 'A6' have been validated by the
   LoST server.  The server considered the postal code 81675 in the <PC>
   element as not valid for this location.  The 'HNO' token belongs to
   the class of unchecked location tokens.



(page 19 continued on part 2)

Next RFC Part