Network Working Group
ECRIT                                                          T. Hardie
Internet-Draft                                            Qualcomm, Inc.
Intended status: Standards Track                               A. Newton
Expires: April 25, July 21, 2007                                         SunRocket
                                                          H. Schulzrinne
                                                             Columbia U.
                                                           H. Tschofenig
                                           Siemens
                                                        October 22, 2006 Networks GmbH & Co KG
                                                        January 17, 2007

            LoST: A Location-to-Service Translation Protocol
                      draft-ietf-ecrit-lost-02.txt
                      draft-ietf-ecrit-lost-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 April 25, July 21, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

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 PSAP for emergency services.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology and Requirements Notation  . . . . . . . . . . . .  6
   3.  Overview of Protocol Usage . . . . . . . .  6
   3.  Terminology . . . . . . . . . .  7
   4.  LoST Uniform Resource Locators and Their Resolution  . . . . .  8
   5.  The <mapping> Element  . . . . . . . . . .  7
   4.  Overview of Protocol Usage . . . . . . . . . .  9
     5.1.  Data source and version: The 'source', 'sourceId' and
           'version' Attributes . . . . . . . .  8
   5.  LoST Uniform Resource Locators and Their Resolution . . . . .  9
   6.  Mapping a Location and Service to URLs: <findService> . . . . 10
     6.1.  Overview . .  9
     5.2.  Time of Last Update: The 'lastUpdated' Attribute . . . . .  9
     5.3.  Validity: The 'expires' Attribute  . . . . . . . . . . . .  9
     5.4.  Describing the Service with the <displayName> Element  . . 10
     5.5.  The Mapped Service:  the <service> Element . . . . . . . . 10
     6.2.  Examples
     5.6.  Defining the Service Region with the <serviceBoundary>
           Element  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       6.2.1.  Example Using Geodetic Coordinates .
     5.7.  Service Boundaries by Reference: the
           <serviceBoundaryReference> Element . . . . . . . . . 10
       6.2.2.  Civic Address Mapping Example . . . 11
     5.8.  The Service Number . . . . . . . . . 11
     6.3.  Components of <findService> Request . . . . . . . . . . . 13
       6.3.1.  The <location> 11
     5.9.  Service URLs: the <uri> Element  . . . . . . . . . . . . . 11
   6.  Path of Request:  <path> Element . . . 13
       6.3.2.  The <service> Element . . . . . . . . . . . . 12
   7.  Mapping a Location and Service to URLs: <findService>  . . . . 13
       6.3.3.  Recursion or Redirection
     7.1.  Overview . . . . . . . . . . . . . . . 13
       6.3.4.  Configuring the Response . . . . . . . . . . 13
     7.2.  Examples . . . . . 14
     6.4.  Components of the Mapping Response
           <findServiceResponse> . . . . . . . . . . . . . . . . . . 16
       6.4.1.  Source of Response:  <via> Element . . 13
       7.2.1.  Example Using Geodetic Coordinates . . . . . . . . 16
       6.4.2.  Service URLs: the <uri> Element . . 13
       7.2.2.  Civic Address Mapping Example  . . . . . . . . . 16
       6.4.3.  Describing the Service with the <displayName>
               Element . . . 14
     7.3.  Components of the <findService> Request  . . . . . . . . . 16
       7.3.1.  The <location> Element . . . . . . . . . . . 17
       6.4.4.  Approximating Services:  the <service> Element . . . . 17
       6.4.5.  Defining the Service Region with . 16
       7.3.2.  Identifying the
               <serviceBoundary> Service:  The <service> Element  . . . 17
       7.3.3.  Recursion  . . . . . . . . . . . . 17
       6.4.6.  Service Boundaries by Reference: the
               <serviceBoundaryReference> Element . . . . . . . . . . 17
       6.4.7.  The
       7.3.4.  Service Number Boundary . . . . . . . . . . . . . . . . . . 18
       6.4.8. . 17
       7.3.5.  Requesting Civic Address Location Validation . . . . . . . . . 17
     7.4.  Components of the Mapping Response
           <findServiceResponse>  . . . . . . 18
       6.4.9.  Validity: The 'timeToLive' Attribute . . . . . . . . . 18
   7.  Retrieving the Service Boundary via <getServiceBoundary> . . . 19
       7.4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 19
       7.4.2.  Civic Address Validation:  the
               <locationValidation> Element . . . . . . . . . . . . . 20
   8.  Retrieving the Service Boundary via <getServiceBoundary> . . . 21
   9.  List Services: <listServices>  . . . . . . . . . . . . . . . . 21
   9. 24
   10. List Services By Location: <listServicesByLocation>  . . . . . 25
   11. Location Profiles  . . . . . . . . . . . . . . . . . . . . . . 23
     9.1. 27
     11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 23
     9.2. 28
     11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 26
     9.3. 30
     11.3. Basic Civic Profile  . . . . . . . . . . . . . . . . . . . 26
   10. Error Handling . . 31
   12. Errors, Warnings, and Redirects  . . . . . . . . . . . . . . . 32
     12.1. Errors . . . . . . . 27
     10.1. Basic Errors . . . . . . . . . . . . . . . . . . . 32
     12.2. Warnings . . . . 27
     10.2. Response Errors . . . . . . . . . . . . . . . . . . . . . 27
     10.3. 33
     12.3. Redirects  . . . . . . . . . . . . . . . . . . . . . . . . 28
   11. 34
   13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 29
   12. 35
   14. Relax NG Schema  . . . . . . . . . . . . . . . . . . . . . . . 30
   13. 36
   15. Internationalization Considerations  . . . . . . . . . . . . . 37
   14. 43
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 38
     14.1. 44
     16.1. U-NAPTR Registrations  . . . . . . . . . . . . . . . . . . 38
     14.2. 44
     16.2. Content-type registration for 'application/lost+xml' . . . 38
     14.3. 44
     16.3. LoST Relax NG Schema Registration  . . . . . . . . . . . . 40
     14.4. 46
     16.4. LoST Namespace Registration  . . . . . . . . . . . . . . . 40
     14.5. 46
     16.5. URL Registration Template  . . . . . . . . . . . . . . . . . . 41
     14.6. 47
     16.6. LoST Location Profile Registry . . . . . . . . . . . . . . 42
   15. 48
   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 43
   16. 49
   18. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 44
   17. 50
   19. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 45
   18. 52
   20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
     18.1. 53
     20.1. Normative References . . . . . . . . . . . . . . . . . . . 46
     18.2. 53
     20.2. Informative References . . . . . . . . . . . . . . . . . . 47 54
   Appendix A.  Non-Normative RELAX NG Schema in XML Syntax . . . . . 48 55
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 69
   Intellectual Property and Copyright Statements . . . . . . . . . . 62 70

1.  Introduction

   This document describes a protocol for mapping a service identifier
   [10] and location information compatible with PIDF-LO [8] [8], namely
   revised civic location information [11] and GML [13]) to one or more
   service contact URIs. URL.  Example contact URI service URL 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 any service URN.  For example, in the United States,
   the "2-1-1" and "3-1-1" services service numbers follow a similar
   location-to-service 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 URIs 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. validation (see Section 3.5 of [18]
   for a description of validation).  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, trips and to provide robustness against network failures, LoST
   caches individual mappings and indicates the region for which the
   same answer would be returned ("service region").

   As currently defined, 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 (seeker or resolver) and the mapping server (resolver
   or other servers).  The relationship between 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 [10]) 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 (URI) and returns those URIs along with optional
   information
   information, such as hints about the service boundary 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 URL (Section 5). 4).  In
   addition to the mapping function described in Section 6, 7, the protocol
   also allows to retrieve the service boundary (see Section 7 8) and to
   list the services available for a particular location (see
   Section 8. 10) or supported by a particular server (see Section 9).

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

3.  Terminology

   This document furthermore uses the terminology defined in [18].

   In examples, the XML sent by the client is prepended with "C:" and
   the XML sent by the server is prepended with "S:".

4.

3.  Overview of Protocol Usage

   The client may perform the mapping at any time.  Among the common
   triggers for mapping requests are:

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

   2.  When the client detects that its location has changed
       sufficiently that it is outside the bounds of the service region
       returned in an earlier LoST query.

   3.  When cached mapping information has expired.

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

   A service-specific BCP Best Current Practice (BCP) document, such as [20]
   [20], 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
   according to at their time-to-live value expiration time (see
   Section 6.4.9, 5.3), or they become invalid if the caller's device moves
   beyond the boundaries of the service region.

5.

4.  LoST Uniform Resource Locators and Their Resolution

   LoST servers are identified by LoST Uniform Resource Locators (URLs),
   which follow the format of URLs defined in RFC 3986 [7], with the
   following ABNF:

      LoST-URI = "lost:" host

   'host' is defined in Section 3.2.2 of RFC 3986 [7].

   An example is 'lost:lostserver.example.com'

   If a LoST URL contains a host name rather than an IP address, clients
   need to use U-NAPTR [12] using the U-NAPTR 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 resolve the LoST URL "lost:example.com"
   to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL
   http://lostserver.example.com, with the former being preferred.

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

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

6.1.  Overview

5.  The <findService> query constitutes <mapping> Element

   The <mapping> element is the core of the LoST
   functionality, mapping civic or geodetic locations to URLs data element in LoST, describing a
   service region and
   associated data.  After giving an example, we enumerate the elements
   of associated service URLs.  Its parameters
   indicate when the query mapping was last updated, how long it is valid, its
   version and response.

6.2.  Examples

6.2.1.  Example Using Geodetic Coordinates the authoritative source for the mapping, along with a
   unique identifier.  Elements within the <mapping> element then
   provide a human-readable description, the service URN, a service
   boundary, the service URIs, and a service number.  All elements
   except the service URN are optional.  Below, we describe the
   components in turn.

5.1.  Data source and version: The following 'source', 'sourceId' and 'version'
      Attributes

   The 'source', 'sourceId' and 'version' attributes uniquely identify a
   particular mapping record.  They are created by the authoritative
   source for a mapping and never modified when a mapping is an example served from
   a cache.  The 'source' attribute contains a LoST URL identifying the
   authoritative generator of mapping the mapping.  The 'sourceId' attribute
   identifies a particular mapping.  The attribute contains a token,
   which is opaque, but MUST be unique among all different mappings
   maintained by the authoritative source for that particular service.
   For example, a UUID is a suitable format.  The 'version' attribute is
   a positive integer that is incremented by one for each change in the
   mapping.  Thus, a higher version number refers to a more recent
   mapping.  A mapping maintains its sourceId value as long as it
   remains logically the same, e.g., represents the same service
   boundary or replaces an earlier service boundary.  A receiver should
   be able to replace a location using
   geodetic coordinates, mapping with another one having the same
   'source' and 'sourceId' and a higher version number.  All three
   attributes are REQUIRED for all <mapping> elements.

5.2.  Time of Last Update: The 'lastUpdated' Attribute

   The 'lastUpdated' attribute describes when the service associated mapping was last
   changed.  The contents of this attribute is a timezoned XML type
   dateTime, in canonical representation.  The attribute is REQUIRED.

5.3.  Validity: The 'expires' Attribute

   The 'expires' attribute contains the absolute time until which the
   mapping is to be considered valid.  The contents of this attribute is
   a timezoned XML type dateTime, in canonical representation.  See
   Section 3 regarding how this value is to be utilized with a cache.
   The 'expires' attribute is REQUIRED to be included in the <mapping>
   element.

   On occasion, a resolver may be forced to return an expired mapping if
   it cannot reach the authoritative server or the server fails to
   return a usable answer.  Seekers and resolvers MAY cache the mapping
   so that they have at least some information available.  Resolvers
   SHOULD re-attempt the query each time a seeker requests a mapping.

5.4.  Describing the Service with the <displayName> Element

   The <displayName> element describes the police
   (urn:service:sos.police).

   <?xml version="1.0" encoding="UTF-8"?>
   <findService xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml" recursive="true"
     include="uri service serviceNumber displayName serviceBoundary">
     <location
       profile="urn:ietf:params:lost:location-profile:geodetic-2d">
       <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
          <p2:pos>40.8089897 -73.9612492</p2:pos>
       </p2:Point>
     </location>
     <service>urn:service:sos.police</service>
   </findService>

                 Figure 2: with a string that is
   suitable for display to human users, annotated with the 'xml:lang'
   attribute that contains a language tag to aid in the rendering of
   text.

5.5.  The Mapped Service:  the <service> Element

   The 'service' element identifies the service for which this mapping
   applies.  It is usually the same service URN as in the request.
   However, if the requested service, identified by the service URN [10]
   in the <service> element in the request, does not exist for the
   location indicated, the server can either return an
   <serviceNotImplemented> (Section 12.1) error or can provide an
   alternate service that approximates the desired service for that
   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.  The <service> element may also
   be required if the mapping is to be digitally signed.

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

   A <findService> Geodetic Query

   Given response can 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.7).  If a client moves outside the service
   area and wishes to obtain current service data, it MUST send 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 different location profile, identified by the
   'profile' atribute.  The client only processes the first element that
   it can understand according to its list of supported location
   profiles.  Thus, the elements are alternative descriptions of the
   same service region, not additive geometries.

   The server returns all suitable service regions, using all available
   location profiles, so that intermediate caches have this information
   available for future queries.

5.7.  Service Boundaries by Reference: the <serviceBoundaryReference>
      Element

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

   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 refreshing the boundary information even if the cached service
   response has gotten stale.

5.8.  The Service Number

   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.9.  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 Request:  <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 URL.  The order of <via> elements corresponds to
   the order of LoST servers, i.e., the first <via> element identifies
   the query above, a server would respond with a service, and
   information related to that service.  In first received the example below, request from the seeker.  The
   authoritative server has mapped copies the location given by <path> element verbatim into the client for
   response.

   If a police
   service to the New York City Police Deparment, instructing query is answered iteratively, the client querier includes all servers
   that it may contact them via the URIs sip:nypd@example.com and
   xmpp:nypd@example.com.  The server has also already contacted.

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

7.  Mapping a
   geodetic, two-dimensional boundary for this service Location and time-to-live
   value of 3,600 seconds.  This instructs Service to URLs: <findService>

7.1.  Overview

   The <findService> query constitutes the client that if its
   location changes beyond core of the give service boundary LoST
   functionality, mapping civic or if 3,600 seconds
   has elapsed, it would need geodetic locations to requery for this information.

   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml" timeToLive="3600">
     <displayName xml:lang="en">
       New York City Police Department
     </displayName>
     <service>urn:service:sos.police</service>
     <serviceBoundary
       profile="urn:ietf:params:lost:location-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>
   </findServiceResponse>

             Figure 3: A <findServiceResponse> Geodetic Answer

6.2.2.  Civic Address Mapping URLs and
   associated data.  After giving an example, we enumerate the elements
   of the query and response.

7.2.  Examples

7.2.1.  Example Using Geodetic Coordinates

   The following is an example of mapping a service to a location much
   like the example in Section 6.2.1, but using civic address location
   information.  In this example, the client requests
   geodetic coordinates, for the service associated with the police (urn:service:sos.police) along with a specific
   civic address (house number 96 on a street named Neu Perlach in
   Munich, Germany).
   (urn:service:sos.police).

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

     <location
       profile="urn:ietf:params:lost:location-profile:basic-civic">
       <civicAddress
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>Germany</country>
         <A1>Bavaria</A1>
         <A3>Munich</A3>
         <A6>Neu Perlach</A6>
         <HNO>96</HNO>
         <PC>81675</PC>
       </civicAddress> 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 4: 2: A <findService> Civic Address Query 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 M&#557;nchen Polizei-Abteilung, New York City Police Deparment, 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
   and time-to-live value of 3,600 seconds.  This instructs the client
   that if its location changes beyond the give service boundary (i.e.
   beyond the city of Munich) or if 3,600 seconds has elapsed, it would
   need to requery for this information.

   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceResponse
     xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600">
     <displayName xml:lang="de">
       M&#557;nchen Polizei-Abteilung
     </displayName>
     <service>urn:service:sos.police</service>
     <serviceBoundary
       profile="urn:ietf:params:lost:location-profile:basic-civic">
       <civicAddress
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>Germany</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>
   </findServiceResponse>

          Figure 5: A <findServiceResponse> Civic Address Answer

6.3.  Components of <findService> Request

6.3.1.  The <location> Element

   The <findService> query communicates location using one or more
   <location> elements, which MUST conform to a location profile
   (Section 9).

6.3.2.  The <service> Element

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

6.3.3.  Recursion or Redirection

   LoST <findService> queries can be recursive or iterative, as
   indicated by the 'recursive' attribute.  A value of "true" indicates
   a recursive query, a value of "false" an iterative query, with
   iterative being the default.  When the LoST server cannot answer the
   query and the query requested iterative resolution, it will return an
   <iterativeSearchExhausted> (Section 10.3) error message with the LoST
   URI pointing to a different LoST server that the LoST client should
   contact.  In recursive mode, the LoST server initiates a query and
   returns the result to the original querier, inserting a <via> element
   to track the response chain.

6.3.4.  Configuring the Response

   The 'include' attribute enumerates all the XML elements that the
   client wants may contact them via the LoST URIs "sip:nypd@example.com" and
   "xmpp:nypd@example.com".  The server to provide in has also given the mapping response. client a
   geodetic, two-dimensional boundary for this service.  The
   server ignores any element names mapping was
   last updated on November 1, 2006 and expires on January 1, 2007.
   This instructs the client that it does not understand.  The
   ordering of if its location changes beyond the tokens is immaterial.

   Among other features, it determines whether
   give service boundaries are
   returned and whether they are returned by value boundary or reference
   Section 7, and whether the expiration time has been reached, it
   would need to validate civic locations. requery for this information.

   <?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="lost:authoritative.example"
       sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">
       <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="lost:authoritative.example"/>
       <via source="lost:resolver.example"/>
     </path>
   </findServiceResponse>

             Figure 3: A <findServiceResponse> geodetic answer

7.2.2.  Civic Address validation Mapping Example

   The following is requested by including an example of mapping a service to a location much
   like the XML element names
   that provide address validation example in Section 7.2.1, but using civic address location
   information.  In this example, the 'include' attribute, namely
   'valid', 'invalid' and 'unchecked'.  The following example
   demonstrates client requests the service
   associated with police (urn:service:sos.police) along with a specific
   civic address validation.

   C: (house number 6 on a street named Otto-Hahn-Ring in
   Munich, Germany).

   <?xml version="1.0" encoding="UTF-8"?>
   C:
   <findService
   C: xmlns="urn:ietf:params:xml:ns:lost1"
   C:
     recursive="true"
   C:   include="uri serviceNumber invalid valid unchecked">
   C: serviceBoundary="value">
     <location
   C:     profile="urn:ietf:params:lost:location-profile:basic-civic">
   C:
       profile="civic">
       <civicAddress
   C:
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
   C:
         <country>Germany</country>
   C:
         <A1>Bavaria</A1>
   C:
         <A3>Munich</A3>
   C:       <A6>Neu Perlach</A6>
   C:       <HNO>96</HNO>
   C:
         <A6>Otto-Hahn-Ring</A6>
         <HNO>6</HNO>
         <PC>81675</PC>
   C:
       </civicAddress>
   C:
     </location>
   C:
     <service>urn:service:sos.police</service>
   C:
   </findService>

   S: <?xml version="1.0" encoding="UTF-8"?>
   S: <findServiceResponse
   S:   xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600">
   S:   <displayName xml:lang="de">
   S:     M&#557;nchen Polizei-Abteilung
   S:   </displayName>
   S:   <service>urn:service:sos.police</service>
   S:   <serviceBoundary
   S:     profile="urn:ietf:params:lost:location-profile:basic-civic">
   S:     <civicAddress
   S:        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
   S:        <country>Germany</country>
   S:        <A1>Bavaria</A1>
   S:        <A3>Munich</A3>
   S:        <PC>81675</PC>
   S:     </civicAddress>
   S:   </serviceBoundary>
   S:   <uri>sip:munich-police@example.com</uri>
   S:   <uri>xmpp:munich-police@example.com</uri>
   S:   <serviceNumber>110</serviceNumber>
   S:   <valid>country A1 A3 A6</valid>
   S:   <invalid>PC</invalid>
   S: </findServiceResponse>

               Figure 6: Address Validation Exchange

6.4.  Components of the Mapping Response <findServiceResponse>

6.4.1.  Source of Response:  <via> Element 4: A <findServiceResponse> indicates the source of <findService> civic address query

   Given the response by
   including query above, a <via> element server would respond with a LoST URL as service, and
   information related to that service.  In the example below, the first <via> element.
   Thus, each
   server "initials" its own response.  Thus, responses to
   iterative queries contain one <via> element, while responses has mapped the location given by the client for a police
   service to
   recursive queries the Muenchen Polizei-Abteilung, instructing the client
   that it may reach contact them via the original querier with multiple <via>
   elements, one for each URIs sip:munich-police@example.com
   and xmpp:munich-police@example.com.  The server that was used in has also given the resolution.
   client a civic address boundary (the city of Munich) for this
   service.  The
   following <findServiceResponse> example illustrates mapping was last updated on November 1, 2006 by the use
   authoritative source "lost: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 city of <via>: Munich) or after January 1, 2007.

   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceResponse
     xmlns="urn:ietf:params:xml:ns:lost1" timeToLive="3600">
     <via>lost:esgw.uber-110.de.example</via>
     <via>lost:polizei.munchen.de.example</via> xmlns="urn:ietf:params:xml:ns:lost1">
     <mapping
       expires="2007-01-01T01:44:33Z"
       lastUpdated="2006-11-01T01:00:00Z"
       source="lost:esgw.ueber-110.de.example"
       sourceId="e8b05a41d8d1415b80f2cdbb96ccf109" version="1" >
       <displayName xml:lang="de">
       M&#557;nchen
         Muenchen Polizei-Abteilung
       </displayName>
       <service>urn:service:sos.police</service>
       <serviceBoundary
         profile="urn:ietf:params:lost:location-profile:basic-civic">
         <civicAddress
           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
           <country>Germany</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="lost:esgw.ueber-110.de.example"/>
       <via source="lost:polizei.muenchen.de.example"/>
     </path>
   </findServiceResponse>

          Figure 7: An Example of a Response Using <via>

   The example above indicates that the this answer was given to the
   responding server by the LoST server at esgw.uber-110.de.example,
   which got the answer from the LoST server at
   polizei.munchen.de.example.

6.4.2.  Service URLs: the <uri> Element

   The response returns the service URLs in one or more <uri> elements.
   The URLs MUST be absolute URLs.

6.4.3.  Describing the Service with the <displayName> Element

   The <displayName> element describes the service with a string that is
   suitable for display to human users, annotated with the 'xml:lang'
   attribute that contains a language tag to aid in the rendering of
   text.

6.4.4.  Approximating Services:  the <service> Element

   If the requested service, identified by 5: A <findServiceResponse> civic address answer

7.3.  Components of the service URN [10] in <findService> Request

   The <findService> request includes attributes that govern whether the
   <service> element
   request is handled iteratively or recursively, whether location
   validation is performed and which elements must be contained in the request, does not exist for the
   response.

7.3.1.  The <location> Element

   The <findService> query communicates location
   indicated, the server can either return an <serviceNotImplemented>
   (Section 10.2) error using one or can provide an alternate service that
   approximates the desired service for that location.  In the latter
   case, the server more
   <location> elements, which MUST include conform to a <service> location profile (see
   Section 11).  There MUST be no more than one location element with the
   alternative service URN. for
   each distinct location profile.  The choice order of service URN location objects is left to local
   policy, but
   significant; the alternate service should be able to satisfy server uses the
   original service request.

6.4.5.  Defining first location object where it
   understands the Service Region with location profile.

7.3.2.  Identifying the <serviceBoundary> Service:  The <service> Element

   A response can indicate the region for which

   The type of service desired is specified by the <service> element.
   It contains service URL returned
   would be URNs from the same as registry established in the actual query, the so-called service
   region.  The service region [10].

7.3.3.  Recursion

   LoST <findService> and <listServicesByLocation> queries can be
   recursive, as indicated by value or by reference
   Section 6.4.6.  If a client moves outside the service area, it MUST
   send 'recursive' attribute.  A value of
   "true" indicates a new query recursive query, with its current location to obtain valid service
   data.  The service region the default being "false"
   when the attribute is described by value in one or more
   <serviceBoundary> elements, each formatted according omitted.  In recursive mode, the LoST server
   initiates queries on behalf of the requester and returns the result
   to a different
   location profile.  The client only processes the first requester, inserting a <via> element that
   it can understand according to its list of supported location
   profiles.  Thus, track the response
   chain.  The <via> elements are alternative descriptions appended in responses in order of
   visit, i.e., the
   same service region, not additive geometries.

   The first <via> element contains the authoritative
   server returns all suitable service regions, using all available
   location profiles, so and <via> elements below indicate servers that intermediate caches have this information
   available for future queries.

6.4.6.  Service Boundaries by Reference: the <serviceBoundaryReference>
        Element

   Since geodetic service boundaries may contain thousands of points and
   thus be quite large, clients may opt to conserve bandwidth and
   request a reference response
   traversed on its way back to the service boundary instead of the value
   described in Section 6.4.5.  The identifier of original querier.

7.3.4.  Service Boundary

   LoST <mapping> elements can describe the service boundary
   is returned in the <serviceBoundaryReference> element, along with a
   LoST URL identifying the server from where it can be retrieved.  The
   actual either by
   value of the or by reference.  Returning a service boundary reference is then retrieved with
   generally more space-efficient for geospatial (polygon) boundaries
   and if the
   getServiceBoundary (Section 7) boundaries change rarely, but does incur an additional
   <getServiceBoundary> request.  The identifier is querier can express a random token preference
   for one or the other modality with at least 128 bits of entropy
   and can be assumed the 'serviceBoundary' attribute in
   the <findService> request, but the server makes the final decision as
   to be globally unique.  The identifier uniquely
   references whether to return a particular boundary; reference or a value.  Servers SHOULD NOT
   return a by-value service boundaries if the boundary changes, querier requested a new
   identifier must
   reference.

7.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 chosen.  Because of these properties, a client
   receiving a mapping false.  The response can simply check if it already has a
   copy of is described in
   Section 7.4.2.  The example in Figure 6 demonstrates address
   validation, omitting the boundary standard response elements.

   <?xml version="1.0" encoding="UTF-8"?>
   <findService
     xmlns="urn:ietf:params:xml:ns:lost1"
     recursive="true"
     validateLocation="true"
     serviceBoundary="value">
     <location 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 6: A <findService> query with that identifier.  If so, it can skip
   checking address validation request
   <?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="lost:authoritative.example"
       sourceId="4db898df52b84edfa9b6445ea8a0328e"
       version="1" >
       <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>Germany</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>
     </locationValidation>
     <path>
       <via source="lost:authoritative.example"/>
       <via source="lost:resolver.example"/>
     </path>
   </findServiceResponse>

     Figure 7: A <findServiceResponse> message with the server whether the boundary has been updated.
   Since service boundaries are likely to remain unchanged for extended
   periods address validation
                                information

7.4.  Components of time, possibly exceeding the normal lifetime Mapping Response <findServiceResponse>

7.4.1.  Overview

   Mapping responses consist of the
   service URL, this approach avoids refreshing <mapping> element (Section 5)
   describing the boundary mapping itself, possibly followed by warnings
   (Section 12.2), location validation information
   even if (Section 7.4.2), and
   an indication of the path (Section 6) the cached service response has gotten stale.

6.4.7.  The Service Number

   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.

6.4.8. taken.

7.4.2.  Civic Address Validation 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 MUST include this
   information if the 'validateLocation' attribute in the request was
   true.  Each element contains a list of tokens separated by white
   space, enumerating the civic location lables 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. <valid> list.

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

6.4.9.  Validity: The 'timeToLive' Attribute

   The timeToLive attribute contains the number of seconds the response
   is to be considered valid.  The contents of this attribute is a
   positive integer.  See Section 4 regarding how this value is to be
   utilized with a cache.  [TBD: This could also be an absolute time.]

7.

8.  Retrieving the Service Boundary via <getServiceBoundary>

   As discussed in Section 6.4.5, 5.6, the <findService> response <findServiceResponse> can return a
   globally unique identifier in the 'serviceBoundary' attribute that
   can be used to retrieve the service boundary, rather than returning
   the boundary by value.  This is shown in the example in Figure 8.
   The client can then retrieve the boundary using the
   <getServiceBoundary> request and obtains the boundary in the
   <getServiceBoundaryResponse>, illustrated in the example in Section 7.
   Figure 10.  The client issues the request to the server identified in
   the 'server' attribute of the <serviceBoundaryReference> element.

   C:
   These requests are always directed to the authoritative server and do
   not recurse.

   <?xml version="1.0" encoding="UTF-8"?>
   C:
   <findService
     xmlns="urn:ietf:params:xml:ns:lost1"
   C:
     xmlns:p2="http://www.opengis.net/gml"
     recursive="true"
   C:   include="uri service serviceNumber displayName
   C:   serviceBoundaryReference">
   C:
     serviceBoundary="reference">
     <location
   C:     profile="urn:ietf:params:lost:location-profile:geodetic-2d">
   C: profile="geodetic-2d">
       <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
   C:     <p2:pos>40.809 -73.9612</p2:pos>
   C:
          <p2:pos>37.775 -122.422</p2:pos>
       </p2:Point>
   C:
     </location>
   C:
     <service>urn:service:sos.police</service>
   C:
   </findService>

   S:

    Figure 8: <findService> request and response with service boundary
                                 reference
   <?xml version="1.0" encoding="UTF-8"?>
   S:
   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
   S:   timeToLive="3600">
   S:
     xmlns:p2="http://www.opengis.net/gml">
     <mapping
       expires="2007-01-01T01:44:33Z"
       lastUpdated="2006-11-01T01:00:00Z"
       source="lost:authoritative.example"
       sourceId="7e3f40b098c711dbb6060800200c9a66"
       version="1">
       <displayName xml:lang="en">
   S:
         New York City Police Department
   S:
       </displayName>
   S:
       <service>urn:service:sos.police</service>
   S:
       <serviceBoundaryReference server="lost:nypd.example.com"
   S:     key="7214148E0433AFE2FA2D48003D31172E"/>
   S:
         source="lost:authoritative.example"
         key="7214148E0433AFE2FA2D48003D31172E" />
       <uri>sip:nypd@example.com</uri>
   S:
       <uri>xmpp:nypd@example.com</uri>
   S:
       <serviceNumber>911</serviceNumber>
   S:
     </mapping>
     <path>
       <via source="lost:authoritative.example"/>
       <via source="lost:resolver.example"/>
     </path>
   </findServiceResponse>

       Figure 8: findService 9: <findServiceResponse> message with Service Boundary Reference
   C: service boundary
                                 reference

   <?xml version="1.0" encoding="UTF-8"?>
   C:
   <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
   C:
       key="7214148E0433AFE2FA2D48003D31172E"/>

   S: <?xml version="1.0" encoding="UTF-8"?>
   S: <getServiceBoundaryResponse
   S:   xmlns="urn:ietf:params:xml:ns:lost1"
   S:   xmlns:p2="http://www.opengis.net/gml">
   S:
   S:   <serviceBoundary
   S:     profile="urn:ietf:params:lost:location-profile:geodetic-2d">
   S:     <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
   S:       <p2:exterior>
   S:         <p2:LinearRing>
   S:           <p2:pos>40.701 -74.020</p2:pos>
   S:           <p2:pos>40.876 -73.926</p2:pos>
   S:           <p2:pos>40.797 -73.936</p2:pos>
   S:           <p2:pos>40.714 -73.984</p2:pos>
   S:           <p2:pos>40.701 -74.020</p2:pos>
   S:         </p2:LinearRing>
   S:       </p2:exterior>
   S:     </p2:Polygon>
   S:   </serviceBoundary>
   S:
   S: </getServiceBoundaryResponse>

    Figure 9: 10: Requesting a Service Boundary service boundary with getServiceBoundary <getServiceBoundary>

   The <getServiceBoundary> request may also be used to retrieve service
   boundaries that are expressed as civic addresses, as illustrated in
   Figure 10. 11.

   <?xml version="1.0" encoding="UTF-8"?>
   <getServiceBoundaryResponse
     xmlns="urn:ietf:params:xml:ns:lost1">
     <serviceBoundary
       profile="urn:ietf:params:lost:location-profile:basic-civic">
       profile="civic">
           <civicAddress
             xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>US</country>
         <A1>New York</A1>
         <A3>New York</A3>
       </civicAddress>
     </serviceBoundary>
     <path>
       <via source="lost:authoritative.example"/>
       <via source="lost:resolver.example"/>
     </path>
   </getServiceBoundaryResponse>

            Figure 10: Civic Address Service Boundary Response

8. 11: Civic Address Service Boundary Response

9.  List Services: <listServices>

   A LoST client can ask a LoST server for the list of services that it
   understands, primarily for diagnostic purposes.  The query does not
   contain location information, as it simply provides an indication of
   which services the server can look up, not whether a particular
   service is offered for a particular area.  Typically, only top-level
   services are included in the answer, implying support for all sub-
   services.  Since the query is answered by the queried server, there
   is no notion of recursion or indirection and no path indication.  The
   <listServicesByLocation (Section 10) query below can be used to find
   out whether a particular service is offered for a specific location.
   An example request and response are shown in Figure 12.

   <?xml version="1.0" encoding="UTF-8"?>
   <listServices
     xmlns="urn:ietf:params:xml:ns:lost1">
     <service>urn:service:sos</service>
   </listServices>

                Figure 12: Example of <ListServices> query

   <?xml version="1.0" encoding="UTF-8"?>
   <listServicesResponse
    xmlns="urn:ietf:params:xml:ns:lost1">
    <serviceList>
     urn:service:sos.ambulance
     urn:service:sos.animal-control
     urn:service:sos.fire
     urn:service:sos.gas
     urn:service:sos.mountain
     urn:service:sos.marine
     urn:service:sos.physician
     urn:service:sos.poison
     urn:service:sos.police
     urn:service:sos.suicide
    </serviceList>
   </listServicesResponse>

                Figure 13: Example of <ListServiceResponse>

10.  List Services: <listServices> Services By Location: <listServicesByLocation>

   A LoST client can ask a LoST server for the list of services it
   supports. knows
   about for a particular area.  The <listServices> <listServicesByLocation> query
   contains one or more <location> elements, each from a different
   location profile (Section 9), 11), and may contain the <service> element.
   As for <findService>, the server selects the first location element
   that has a profile the server understands and it can operate either
   recursively or iteratively; < via> elements track the progress of the
   request.  By its nature, the query can only indicate the services
   that a particular server can determine, not all possible services
   that might be offered.  Unlike <ListServices>, the answer describes
   the services available at a specific location, not just those
   understood by the server.

   If the query contains the <service>
   element element, the LoST server returns
   only immediate child services of the queried service that are
   available for the provided location.  If the <service> element is
   absent, the LoST service returns all top-level services available for
   the provided location that it knows about.

   A server responds to this query with a <listServicesResponse>
   <listServicesByLocationResponse> response.  This response has may MAY contain
   <via> elements
   (Section 6.4.1) (see Section 6) and must MUST contain a <serviceList>
   element, consisting of a whitespace-separated list of service URNs.
   The query and response are illustrated in Figure 11.

   C: 14 and in Figure 15,
   respectively.

   <?xml version="1.0" encoding="UTF-8"?>
   C: <listServices
   C:
   <listServicesByLocation
     xmlns="urn:ietf:params:xml:ns:lost1"
   C:
     xmlns:p2="http://www.opengis.net/gml"
   C:   recursive="false">
   C:
     recursive="true">
     <location
   C:     profile="urn:ietf:params:lost:location-profile:basic-civic">
   C: profile="geodetic-2d">
       <p2:Point id="point1" srsName="epsg:4326">
   C:
         <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates>
   C:
       </p2:Point>
   C:
     </location>
   C:
     <service>urn:service:sos</service>
   C: </listServices>

   S:
   </listServicesByLocation>

           Figure 14: Example of <ListServicesbyLocation> query
   <?xml version="1.0" encoding="UTF-8"?>
   S: <listServicesResponse
   <listServicesByLocationResponse
    xmlns="urn:ietf:params:xml:ns:lost1">
   S:
    <serviceList>
   S:
     urn:service:sos.ambulance
   S:
     urn:service:sos.animal-control
   S:
     urn:service:sos.fire
   S:
     urn:service:sos.gas
   S:
     urn:service:sos.mountain
   S:
     urn:service:sos.marine
   S:
     urn:service:sos.physician
   S:
     urn:service:sos.poison
   S:
     urn:service:sos.police
   S:
     urn:service:sos.suicide
   S:
    </serviceList>
   S: </listServicesResponse>
    <path>
     <via source="lost:authoritative.example"/>
     <via source="lost:resolver.example"/>
    </path>
   </listServicesByLocationResponse>

               Figure 11: ListService Query 15: Example

9. of <ListServices> response

11.  Location Profiles

   Currently,

   LoST uses location information in <location> elements in requests and
   <serviceBoundary> elements in responses.  Such location information
   may be expressed in a variety of ways.  This variety can cause
   interoperability problems where a request or response contains
   location information in a format not understood by the server or the
   client, respectively.  To achieve interoperability, LoST this document
   defines two
   must-implement mandatory-to-implement baseline location profiles to
   define the manner in which location information is transmitted and makes it transmitted.  It
   possible to standardize other profiles in the future.  The two
   baseline profiles are:

   geodetic-2d:

      a simple profile for two-dimensional geodetic location
      information, as described in Section 9.2); 11.2;

   civic:

      a profile consisting of civic address location information, as
      described in Section 9.3. 11.3.

   Requests and responses containing <location> or <serviceBoundary>
   elements MUST contain location information in exactly one of the two
   baseline profiles, in addition to zero or more additional profiles.
   The ordering of location information indicates a preference on the
   part of the sender.

   Standards action may create other is required for defining new profiles.  A location
   profile MUST define:

   1.  The token identifying it in the LoST location profile registry;

   2.  The formal definition of the XML to be used in requests, i.e., an
       enumeration and definition of the XML child elements of the
       <location> element;

   3.  The formal definition of the XML to be used in responses, i.e.,
       an enumeration and definition of the XML child elements of the
       the
       <serviceBoundary> element;

   4.  The declaration of whether geodetic-2d or civic is to be used as
       the baseline profile.  It is necessary to explicitly declare the
       baseline profile as future profiles may be combinations of
       geodetic and civic location information.

9.1.

11.1.  Location Profile Usage

   A location profile is identified by a URN token in the
   urn:ietf:params:lost:location-profile registry.  (Note that this is
   not an XML schema or namespace identifier.) IANA-maintained
   registry (Section 16.6).  Clients send location information compliant
   with a location profile, and servers respond with location
   information compliant with that same location profile.

   When a LoST client sends a <findService> request which that provides
   location information, it contains includes one or more <location> elements.
   Each of these elements contains location information compliant with a
   location profile and specifies which profile has been used in the
   'profile' attribute.  This allows the client to convey location
   information for multiple location profiles in the same request.

   When a LoST server sends a response which that contains location
   information, it uses the <serviceBoundary> elements much like the
   client uses the <location> elements.  Each <serviceBoundary> element
   contains location information conformant to the location profile
   specified in the 'profile' attribute.  This allows the server to send
   location information compliant with multiple location profiles.

   Using the location profiles defined in this document, the following
   rules insure basic interoperatiblity between clients and servers:

   1.  A client MUST be capable of understanding the response for the
       baseline profiles it used in the request.

   2.  If a client sends location information conformant to any location
       profile other than geodetic-2d or civic, it MUST also send, in
       the same request, location information conformant to one of the
       baseline profiles.  Otherwise, the server might not be able to
       understand the request.

   3.  There can only be one instance of each location profile in a
       query.

   4.  Servers MUST implement the geodetic-2d and civic profiles.

   4.

   5.  A server ignores any uses the first-listed location information using non-baseline
       profiles profile that it does not understand.

   5.
       understands and ignores the others.

   6.  If a server receives a request that only contains location
       information using profiles it does not understand, the server
       responds with a <locationProfileError> (Section 10.2). 12.1).

   7.  The <serviceBoundary> element MUST use the same location profile
       that was used to retrieve the answer and indicates which profile
       has been used with the 'profile' attribute.

   These rules enable the use of location profiles not yet specified,
   while ensuring baseline interoperability.  Take, for example, this
   scenario.  Client X has had its firmware upgraded to support the
   uber-complex-3D location profile.  Client X sends location
   information to Server Y, which does not understand the
   uber-complex-3D location profile.  If Client X also sends location
   information using the geodetic-2D baseline profile, then Server Y
   will still be able to understand the request and provide an
   understandable response, though with location information that might
   not be as precise or expressive as desired.  This is possible because
   both Client X and Server Y understand the baseline profile.  The
   following transaction, where the XML sent by the client is prepended
   with 'C:' and the XML sent by the server is prepended with 'S:',
   demonstrates this:

   C:

   <?xml version="1.0" encoding="UTF-8"?>
   C: <findService xmlns="urn:ietf:params:xml:ns:lost1"
   C:   xmlns:p2="http://www.opengis.net/gml"
   C:   recursive="true" include="uri serviceNumber">
   C:   <location
   C:     profile="urn:ietf:params:lost:location-profile:geodetic-2d">
   C:     <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
   C:        <p2:pos>40.8089897 -73.9612492</p2:pos>
   C:     </p2:Point>
   C:   </location>
   C: encoding="UTF-8"?>
   <findService
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"
     recursive="true"
     serviceBoundary="value">
     <location
   C:     profile="
   C:       urn:ietf:params:lost:location-profile:uber-complex-3d">
   C: profile="uber-complex-3d">
       <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
   C:
          <p2:pos>37.775 -122.422 25</p2:pos>
   C: -122.422</p2:pos>
       </p2:Point>
   C:
         <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
   C:
           <p2:exterior>
   C:
             <p2:LinearRing>
   C:           <p2:pos>40.80 -73.96 24</p2:pos>
   C:           <p2:pos>40.81 -73.95 27</p2:pos>
   C:           <p2:pos>40.80 -73.96 24</p2:pos>
   C:
               <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>
   C:
            </p2:exterior>
   C:
         </p2:Polygon>
   C:
       <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
          <p2:pos>-122.422 37.775</p2:pos>
       </p2:Point>
     </location>
     <location 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>
   C:
     <service>urn:service:sos.police</service>
   C:
   </findService>

   S:

    Figure 16: Example of a <findServices> query with baseline profile
                             interoperability

   <?xml version="1.0" encoding="UTF-8"?>
   S:
   <findServiceResponse
     xmlns="urn:ietf:params:xml:ns:lost1"
   S:   xmlns:p2="http://www.opengis.net/" timeToLive="3600">
   S:   <locationProfileError
   S:     unsupportedProfiles="
   S:      urn:ietf:params:lost:location-profile:uber-complex-3d"
   S:     message="Too sophisticated for us." xml:lang="en"/>
   S:
     xmlns:p2="http://www.opengis.net/">
     <mapping
       expires="2007-01-01T01:44:33Z"
       lastUpdated="2006-11-01T01:00:00Z"
       source="lost:authoritative.example"
       sourceId="cf19bbb038fb4ade95852795f045387d"
       version="1">
       <displayName xml:lang="en">
   S:
         New York City Police Department
   S:
       </displayName>
   S:
       <service>urn:service:sos.police</service>
   S:
       <serviceBoundary
   S:     profile="urn:ietf:params:lost:location-profile:geodetic-2d">
   S: profile="geodetic-2d">
         <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
   S:
           <p2:exterior>
   S:
             <p2:LinearRing>
   S:         <p2:pos>40.701 -74.020</p2:pos>
   S:         <p2:pos>40.876 -73.926</p2:pos>
   S:         <p2:pos>40.797 -73.936</p2:pos>
   S:         <p2:pos>40.714 -73.984</p2:pos>
   S:         <p2:pos>40.701 -74.020</p2:pos>
   S:
               <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>
   S:
           </p2:exterior>
   S:
         </p2:Polygon>
   S:
       </serviceBoundary>
   S:
       <uri>sip:nypd@example.com</uri>
   S:
     </mapping>
     <path>
       <via source="lost:authoritative.example"/>
       <via source="lost:resolver.example"/>
     </path>
   </findServiceResponse>

    Figure 12: 17: Example of a findServices query <findServiceResponse> message with baseline
                         profile interoperability

9.2.

11.2.  Two Dimensional Geodetic Profile

   The geodetic-2d location profile is identified by geodetic-2d.
   Clients use this profile by placing a GML [13] <position> element
   within the <location> element.  This is defined by the 'point2D'
   pattern in the LoST schema (see Section 12). 14).

   Servers use this profile by placing a GML [13] <Polygon> element
   within the <serviceBoundary> element.  This is defined by the
   'polygon' pattern in the LoST schema (see Section 12).

9.3. 14).

11.3.  Basic Civic Profile

   The basic-civic location profile is identified by the token 'civic'.
   Clients use this profile by placing a <civicAddress> element, defined
   in [11], within the <location> element.

   Servers use this profile by placing a <civicAddress> element, defined
   in [11], within the <serviceBoundary> element.

10.  Error Handling

   Errors are indicated by error-specific elements.  Depending

12.  Errors, Warnings, and Redirects

   When a LoST server cannot fulfill a request completely, it can return
   either an error or a warning, depending on the
   nature severity of the error, the
   problem.  It returns an error element may occur along with other if no useful response elements, indicating that the request was only partially
   satisfied and that not all information in can be
   returned for the request was processed
   correctly.  Errors labeled as fatal means

10.1.  Basic Errors

   LoST defines query.  It returns a pattern for errors, defined <warnings> element as "errors" part of
   another response element if it was able to respond in part, but the Relax
   NG schema.  This pattern defines a 'message' attribute containing
   human readable text and an 'xml:lang' attribute denoting
   response may not be quite what the language
   of client had desired.  For both
   elements, the human readable text.

   LoST defines 'source' attribute names the following elements as following this pattern:

   badRequest  The server could not parse that originally
   generated the error or warning, such as the authoritative server.
   Unless otherwise understand noted, all elements below can be either an error or
   a
      request.  This is warning, depending on whether a top-level element, and default response, such as a
   mapping, is returned if the
      server did not understand the outermost LoST XML element
      identifying the request.

   serviceSubstitution  The server substituted one service for another.
      See Section 6.4.4.

10.2.  Response included.

12.1.  Errors

   LoST defines a pattern for errors that may generated by referrent
   LoST serves queried on behalf of seekers by a resolving LoST server.
   This defines a pattern builds on for errors, defined as <errors> elements in
   the basic errors Relax NG schema.  This pattern (Section 10.1).  It
   also provides defines a 'message' attribute
   containing human readable text and an 'xml:lang' attribute denoting
   the option language of specifying the source server using the
   'source' attribute, as well as specifying the query that caused the
   error.

   LoST defines the following human readable text.  One or more such error
   elements as are contained in the <errors> element.

   The following errors follow this basic pattern:

   badRequest

      The server could not parse or otherwise understand a request,
      e.g., because the XML was malformed.

   forbidden

      The server refused to send an answer.

   notFound  The server could not find an answer  This generally only occurs
      for recursive queries, namely if the resolver tried to contact the query.

   serviceNotImplemented  The requested service is not implemented.
      authoritative server and was refused.  (For HTTP as the underlying
      protocol, an HTTP 401 error would be returned.)

   internalError

      The server could not satisfy a request due to misconfiguration or
      other operational and non-protocol related reasons.

   serverTimeout  A time out occurred before

   locationProfileUnrecognized

      None of the profiles in the request were recognized by the server
      (see Section 11).

   loop

      During a recursive query, the server was about to visit a server
      that was already in the server list in the <path> element,
      indicating a request loop.

   notFound

      The server could not find an answer was received. to the query.

   serverError

      An answer was received from another LoST server, but it could not
      be parsed or otherwise understood.

   locationProfileError  This error occurs only for
      recursive queries.

   serverTimeout

      A location profile in the query given time out occurred before an answer was received.

   serviceNotImplemented

      The requested service URN is not
      recognized.  The element may also have implemented and no substitution
      was available.

   An example is below:

   <?xml version="1.0" encoding="UTF-8"?>
   <errors xmlns="urn:ietf:params:xml:ns:lost1"
     source="lost:resolver.example">
      <internalError message="Software bug." xml:lang="en"/>
   </errors>

                  Figure 18: Example of an 'unsupportedProfiles'
      attribute, which contains error resonse

12.2.  Warnings

   A response MAY contain zero or more warnings.  This pattern defines a whitespace separated list
   'message' attribute containing human readable text and an 'xml:lang'
   attribute denoting the language of the human readable text.  One or
   more such warning elements are contained in the <warnings> element.

   This version of profile
      URNs.  See Section 9.

10.3. the specification does not define any warning
   elements.

12.3.  Redirects

   A LoST defines a pattern for server can respond indicating that the querier should redirect responses.  This pattern builds
   on
   the basic error pattern (Section 10.1) and query to another server, using the <redirect> element.  The
   element includes a 'url' 'target' attribute indicating the LoST URL that
   the client should SHOULD be contacting next.

   Currently, LoST only defines next, as well as the 'source'
   attribute indicating the server that generated the redirect response
   and a 'message' attribute explaining the reason for the redirect
   response.  During a recursive query, a server receiving a <redirect> element along this
   pattern.

11.
   response can decide whether it wants to follow the redirection or
   simply return the response to its upstream querier.

   An example is below:

   <?xml version="1.0" encoding="UTF-8"?>
   <redirect xmlns="urn:ietf:params:xml:ns:lost1"
     target="lost:eastpsap.example"
     source="lost:westpsap.example"
     message="We have temporarily failed over." xml:lang="en"/>

                 Figure 19: Example of a redirect resonse

13.  LoST Transport

   LoST needs an underlying protocol transport mechanisms to carry
   requests and responses.  This document defines the use of LoST over
   HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future
   documents.  The available transport mechanisms are determined through
   the use of the LoST U-NAPTR application.  In protocols that support
   content type indication, LoST uses the media type application/
   lost+xml.

   When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP
   POST method.  All HTTP responses are applicable.  The HTTP URL is
   derived from the LoST URL via U-NAPTR application, as discussed in
   Section 5.

12. 4.

14.  Relax NG Schema

   This section provides the Relax NG schema used by LoST protocol in
   the compact form.  The verbose form is included in Appendix A.

default namespace = "http://www.opengis.net/gml"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace ns1 = "urn:ietf:params:xml:ns:lost1"

##
##       Location-to-Service Translation Protocol (LoST)
##
##       A LoST XML instance has three request types, each with
##       a cooresponding response type: find service, list services,
##       and get service boundary.
##
start =
  findService
  | listServices
  | listServicesByLocation
  | getServiceBoundary
  | findServiceResponse
  | listServicesResponse
  | listServicesByLocationResponse
  | getServiceBoundaryResponse
  | errors
  | redirect

##
##       The queries.
##
div {
  findService =
    element ns1:findService {
         query,
      element ns1:location { locationInformation }+,
      commonRequestPattern,
      attribute include validateLocation {
           list
        xsd:boolean >> a:defaultValue [ "false" ]
      }?,
      attribute serviceBoundary {
             ("uri"
              | "serviceNumber"
              | "displayName"
              | "service"
              | "valid"
              | "invalid"
              | "unchecked"
        ("reference" | "serviceBoundary"
              | "serviceBoundaryReference")*
           } "value") >> a:defaultValue [ "reference" ]
      }?,
      attribute recursive { xsd:boolean >> a:defaultValue [ "uri serviceNumber" "true" ] }?
    }
  listServices = element ns1:listServices { query commonRequestPattern }
  listServicesByLocation =
    element ns1:listServicesByLocation {
      element ns1:location { locationInformation }*,
      commonRequestPattern,
      attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
    }
  getServiceBoundary =
    element ns1:getServiceBoundary {
      serviceBoundaryKey, extensionPoint
    }
}

##
##       The responses.
##
div {
  findServiceResponse =
    element ns1:findServiceResponse {
         via,
         ((locationProfileError?, serviceSubstitution?, serviceResult)
          | badRequest
          | internalError
          | forbidden
          | notFound
          | serviceNotImplemented
          | serverTimeout
          | serverError
          | movedPermenantly
          | movedTemporarily
          | iterativeSearchExhausted),
         extensionPoint
      mapping+, locationValidation?, commonResponsePattern
    }
  listServicesResponse =
    element ns1:listServicesResponse {
         via,
         ((locationProfileError?,
      serviceList, commonResponsePattern
    }
  listServicesByLocationResponse =
    element ns1:serviceList {
             list ns1:listServicesByLocationResponse { xsd:anyURI* }
           })),
         extensionPoint
      serviceList, commonResponsePattern
    }
  getServiceBoundaryResponse =
    element ns1:getServiceBoundaryResponse {
         (serviceBoundary
          | badRequest
          | internalError
          | forbidden
          | notFound),
         extensionPoint
      serviceBoundary, commonResponsePattern
    }
}

##
##       A pattern common to some of the queries.
##
div {
     query
  commonRequestPattern =
       element ns1:location { locationInformation }+,
       element ns1:service { xsd:anyURI }?,
       extensionPoint,
       attribute recursive service, extensionPoint
}

##
##       A pattern common to responses.
##
div { xsd:boolean >> a:defaultValue [ "true" ] }?
  commonResponsePattern = warnings*, path, extensionPoint
}

##
##       Location Information
##
div {
  locationInformation =
    extensionPoint+,
    attribute profile { xsd:anyURI xsd:NMTOKEN }
}

##
##       Service Boundary
##
div {
  serviceBoundary = element ns1:serviceBoundary { locationInformation }+
}

##
##       Service Boundary Key Reference
##
div {
  serviceBoundaryReference =
    element ns1:serviceBoundaryReference {
      source, serviceBoundaryKey, extensionPoint
    }
  serviceBoundaryKey = attribute key {
         xsd:string { pattern = "[a-zA-Z0-9/+=]+" } xsd:token }
}

##
##       Via       Path -
##       Contains a list of via elements -
##       places through which information flowed
##
div {
     via
  path =
    element ns1:path {
      element ns1:via { xsd:anyURI source, extensionPoint }*
    }
}

##
##       Time-to-live       Expires pattern
##
div {
     timeToLive
  expires = attribute timeToLive expires { xsd:positiveInteger xsd:dateTime }
}

##
##       A QName list

##
div {
  qnameList = list { xsd:QName* }
}

##
##       A location-to-service result. mapping.
##
div {
     serviceResult
  mapping =
    element ns1:mapping {
      element ns1:displayName {
        xsd:string,
        attribute xml:lang { xsd:language }
       }?,
       element ns1:service { xsd:anyURI }?,
      }*,
      service,
      (serviceBoundary | element ns1:serviceBoundaryReference { serviceBoundaryKey })?, serviceBoundaryReference)?,
      element ns1:uri { xsd:anyURI }*,
      element ns1:serviceNumber {
        xsd:string { pattern = "[0-9]+" "[0-9*#]+" }
      }?,
      extensionPoint,
      expires,
      attribute lastUpdated { xsd:dateTime },
      source,
      attribute sourceId { xsd:token },
      attribute version { xsd:positiveInteger },
      message
    }
}

##
##       Location validation
##
div {
  locationValidation =
    element ns1:locationValidation {
      element ns1:valid { qnameList }?,
      element ns1:invalid { qnameList }?,
      element ns1:unchecked { qnameList }?,
      extensionPoint
    }
}

##
##       Errors and Warnings Container.
##
div {
  errorContainer =
    (badRequest?
     & internalError?
     & serviceSubstitution?
     & forbidden?
     & notFound?
     & loop?
     & serviceNotImplemented?
     & serverTimeout?
     & serverError?
     & locationProfileUnrecognized?),
    extensionPoint,
       timeToLive,
       message
    source
  errors = element ns1:errors { errorContainer }
  warnings = element ns1:warnings { errorContainer }
}

##
##       Basic Errors
##
div {

  ##
  ##         Error pattern.
  ##
     error
  basicError = message, extensionPoint
  badRequest = element ns1:badRequest { error basicError }
  internalError = element ns1:internalError { error basicError }
  serviceSubstitution = element ns1:serviceSubstitution { error basicError }
   }
   ##
   ##       Recursion Errors.
   ##
   div {

     ##
     ##         Recursion error.
     ##
     recursionError =
       attribute failedReferral { xsd:anyURI }?,
       (findService | listServices | getServiceBoundary)?,
       error
  forbidden = element ns1:forbidden { recursionError },
       timeToLive basicError }
  notFound = element ns1:notFound { recursionError },
       timeToLive basicError }
  loop = element ns1:loop { basicError }
  serviceNotImplemented =
    element ns1:serviceNotImplemented { recursionError },
       timeToLive basicError }
  serverTimeout = element ns1:serverTimeout { recursionError },
       timeToLive basicError }
  serverError = element ns1:serverError { recursionError },
       timeToLive
     locationProfileError basicError }
  locationProfileUnrecognized =
    element ns1:locationProfileError ns1:locationProfileUnrecognized {
      attribute unsupportedProfiles {
           list { xsd:anyURI* } xsd:NMTOKENS },
         recursionError
      basicError
    }
}

##
##       Redirects.       Redirect.
##
div {
  ##
  ##         Redirect pattern
  ##
  redirect =
    element ns1:redirect {
      attribute redirect target { xsd:anyURI },
       error
     movedPermenantly = element ns1:movedPermanently { redirect
      source,
      message,
      extensionPoint
    }
     movedTemporarily =
       element ns1:movedTemporarily { redirect },
       timeToLive
     iterativeSearchExhausted =
       element ns1:iterativeSearchExhausted { redirect },
       timeToLive
}

##
##       Message pattern.       Some common patterns.
##
div {
  message =
    (attribute message { xsd:string },
     attribute xml:lang { xsd:language })?
  service = element ns1:service { xsd:anyURI }?
  source = attribute source { xsd:anyURI }
  serviceList =
    element ns1:serviceList {
      list { xsd:anyURI* }
    }
}

##
##       Patterns for inclusion of elements from schemas in
##       other namespaces.
##
div {

  ##
  ##         Any element not in the LoST namespace.
  ##
  notLost = element * - (ns1:* | ns1:*) { anyElement }

  ##
  ##         A wildcard pattern for including any element
  ##         from any other namespace.
  ##
  anyElement =
    (element * { anyElement }
     | attribute * { text }
     | text)*

  ##
  ##         A point where future extensions
  ##         (elements from other namespaces)
  ##         can be added.
  ##
  extensionPoint = notLost*

  ##
  ##         A 2D point from GML.
  ##
  point2d =
    element position {
         element Point {
      attribute srsName { "urn:ogc:def:crs:EPSG:4326" "urn:ogc:def:crs:EPSG::4326" },
      pos
    }

  ##
  ##         A GML position
  ##
  pos =
    element pos { text }
      list { xsd:double }
    }

  ##
  ##         A Linear Ring from GML.
  ##
  linearRing = element LinearRing {
         element pos { text } pos, pos, pos, pos+ }

  ##
  ##         A Polygon from GML.
  ##
  polygon =
    element Polygon {
      attribute srsName { "urn:ogc:def:crs:EPSG:4979" "urn:ogc:def:crs:EPSG::4326" },
      element exterior { linearRing },
      element interior { linearRing }*
    }
}

13.

                         Figure 20: RelaxNG schema

15.  Internationalization Considerations

   This mechanism is largely for passing protocol information from one
   subsystem to another; as such, most of its elements are tokens not
   meant for direct human consumption.  If these tokens are presented to
   the end user, some localization may need to occur.  The content of
   the <displayName> element and the 'message' attributes may be
   displayed to the end user, and they are thus a complex types designed
   for this purpose.

   LoST exchanges information using XML.  All XML processors are
   required to understand UTF-8 and UTF-16 encodings, and therefore all
   LoST clients and servers MUST understand UTF-8 and UTF-16 encoded
   XML.  Additionally, LoST servers and clients MUST NOT encode XML with
   encodings other than UTF-8 or UTF-16.

14.

16.  IANA Considerations

14.1.

16.1.  U-NAPTR Registrations

   This document registers the following U-NAPTR application service
   tag:

   Application Service Tag:  LoST

   Defining Publication:  The specification contained within this
      document.

   This document registers the following U-NAPTR application protocol
   tags:

   o

      Application Protocol Tag:  http

      Defining Publication:  RFC 2616 [3]

   o

      Application Protocol Tag:  https

      Defining Publication:  RFC 2818 [5]

14.2.

16.2.  Content-type registration for 'application/lost+xml'

   This specification requests the registration of a new MIME type
   according to the procedures of RFC 4288 [9] and guidelines in RFC
   3023 [6].

   MIME media type name:  application

   MIME subtype name:  lost+xml

   Mandatory parameters:  none

   Optional parameters:  charset

      Indicates the character encoding of enclosed XML.

   Encoding considerations:

      Uses XML, which can employ 8-bit characters, depending on the
      character encoding used.  See RFC 3023 [6], Section 3.2.

   Security considerations:

      This content type is designed to carry LoST protocol payloads.

   Interoperability considerations:  None

   Published specification:  RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number of this specification.] this
      document

   Applications which use this media type:

      Emergency and Location-based Systems

   Additional information:

      Magic Number:  None

      File Extension:  .lostxml

      Macintosh file type code:  'TEXT'

   Personal and email address for further information:  Hannes
      Tschofenig, Hannes.Tschofenig@siemens.com

   Intended usage:  LIMITED USE

   Author:

      This specification is a work item of the IETF ECRIT working group,
      with mailing list address <ecrit@ietf.org>.

   Change controller:

      The IESG <iesg@ietf.org>

14.3.

16.3.  LoST Relax NG Schema Registration

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

   Registrant Contact:  IETF ECRIT Working Group, Hannes Tschofenig
      (Hannes.Tschofenig@siemens.com).

   Relax NG Schema:  The Relax NG schema to be registered is contained
      in Section 12. 14.  Its first line is

   default namespace = "urn:ietf:params:xml:ns:lost1"

      and its last line is

   }

14.4.

16.4.  LoST Namespace Registration

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

   Registrant Contact:  IETF ECRIT Working Group, Hannes Tschofenig
      (Hannes.Tschofenig@siemens.com).

   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 Namespace</title>
   </head>
   <body>
     <h1>Namespace for LoST</h1>
     <h2>urn:ietf:params:xml:ns:lost</h2>
     <h2>urn:ietf:params:xml:ns:lost1</h2>
   <p>See <a href="[URL of published RFC]">RFCXXXX
       [NOTE TO IANA/RFC-EDITOR:
        Please replace XXXX with the RFC number of this
       specification.]</a>.</p>
   </body>
   </html>
   END

14.5.

16.5.  URL Registration Template

   This registration template is in accordance with [4].

   URL scheme name:

      lost

   URL scheme syntax:

      See Section 5 4

   Character encoding considerations:

      See Section 5 4

   Intended Use:

      The intended usage is described in this document.

   Application and protocols which use this scheme:

      The usage of the LoST URL scheme is targeted for this document and
      hence for location-based services that make use of the mapping
      protocol specified in this document.

   Interoperability considerations:

      None

   Security considerations:

      See Section 15 17

   Relevant publications:

      This document provides the relevant context for this URL scheme.

   Contact:

      Hannes Tschofenig, Hannes.Tschofenig@siemens.com

   Author/Change controller:

      The IESG <iesg@ietf.org>

14.6.

16.6.  LoST Location Profile Registry

   This document seeks to create a registry of location profile names
   for the LoST protocol.  Profile names are XML tokens.  This registry
   will operate in accordance with RFC 2434 [2], Standards Action.

   geodetic-2d:

      Defined in TBD Section 11.2

   civic:

      Defined in TBD

15. Section 11.3

17.  Security Considerations

   There are multiple threats to the overall system of which service
   mapping forms a part.  An attacker that can obtain service contact
   URIs can use those URIs to attempt to disrupt those services.  An
   attacker that can prevent the lookup of contact URIs can impair the
   reachability of such services.  An attacker that can eavesdrop on the
   communication requesting this lookup can surmise the existence of an
   emergency and possibly its nature, and may be able to use this to
   launch a physical attack on the caller.

   To avoid that an attacker can modify the query or its result, the use
   of channels security, such as TLS, is RECOMMENDED.

   A more detailed description of threats threats and security requirements are
   provided in [17].

18.  Acknowledgments

   We would like to the thank the following working group members for
   the detailed review of previous LoST document versions:

   o  Barbara Stark (Review in Jan. 2007)

   o  Martin Thomson (Review in Dec. 2006, Review Jul. 2006)

   o  Shida Schubert (Review Nov. 2006)

   o  Leslie Daigle (Review Sep. 2006)

   o  Jonathan Rosenberg (Review Jul. 2006)

   We would also like to thank the following working group members for
   their input to selected design aspects of the LoST protocol:

   o  Leslie Daigle and security requirements are
   provided Martin Thomson (Input to DNS-based LoST
      discovery procedure)

   o  John Schnizlein (Authoritive LoST Answers)

   o  Rohan Mahy (Display Names)

   o  James Polk (Error Handling)

   o  Ron Watro and Richard Barnes (Expiry of cached data)

   o  Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James
      Winterbottom (Indication of PSAP Confidence Level)

   o  Martin Thomson (Service Boundary references)

   o  Martin Thomson (Service URN in [17].

16.  Acknowledgments

   [Editor's Note: Names need LoST response message)

   o  Cullen Jennings (Service Boundaries)

   o  Clive D.W. Feather, Martin Thomson (Validation Functionality)

   o  Roger Marshall (PSAP Preference in LoST response)

   o  James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor,
      Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W.
      Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-
      Francois Mule, Pierre Desjardins (Location Profiles)
   o  Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson,
      Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage,
      Keith (List Services functionality)

   o  Thomson, Martin, Michael Hammer (Mapping of Services)

   o  Shida Schubert, James Winterbottom, Keith Drage (default service
      URN)

   o  Otmar Lendl (LoST aggregation)

   The following working group members provided miscellaneous input to be added here.  Forgot it...Sorry.]

17.
   the design of the protocol:

   o  Klaus Darilion

   o  Marc Linsner

   Finally, we would like to particularly thank Brian Rosen as a long
   term contributor who participated in almost every discussion thread.

19.  Open Issues

   Please find open issues at: http://www.ietf-ecrit.org:8080/lost/

18.

20.  References

18.1.

20.1.  Normative References

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

   [2]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.

   [3]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [4]   Petke, R. and I. King, "Registration Procedures for URL Scheme
         Names", BCP 35, RFC 2717, November 1999.

   [5]   Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [6]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [7]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
         January 2005.

   [8]   Peterson, J., "A Presence-based GEOPRIV Location Object
         Format", RFC 4119, December 2005.

   [9]   Freed, N. and J. Klensin, "Media Type Specifications and
         Registration Procedures", BCP 13, RFC 4288, December 2005.

   [10]  Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
         draft-ietf-ecrit-service-urn-05 (work in progress),
         August 2006.

   [11]  Thomson, M. and J. Winterbottom, "Revised Civic Location Format
         for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in
         progress), September 2006.

   [12]  Daigle, L., "Domain-based Application Service Location Using
         URIs and the Dynamic  Delegation Discovery Service (DDDS)",
         draft-daigle-unaptr-00
         draft-daigle-unaptr-01 (work in progress), June October 2006.

   [13]  OpenGIS, "Open Geography Markup Language (GML) Implementation
         Specification", OGC OGC 02-023r4, January 2003.

18.2.

20.2.  Informative References

   [14]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [15]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
         Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
         October 2004.

   [16]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
         December 2004.

   [17]  Taylor, T., "Security Threats and Requirements for Emergency
         Call Marking and Mapping", draft-ietf-ecrit-security-threats-03
         (work in progress), July 2006.

   [18]  Schulzrinne, H. and R. Marshall, "Requirements for Emergency
         Context Resolution with Internet Technologies",
         draft-ietf-ecrit-requirements-12 (work in progress),
         August 2006.

   [19]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
         Framework", draft-ietf-ecrit-mapping-arch-00 draft-ietf-ecrit-mapping-arch-01 (work in
         progress), August December 2006.

   [20]  Rosen, B. and J. Polk, "Best Current Practice for
         Communications Services in support of Emergency  Calling",
         draft-ietf-ecrit-phonebcp-00 (work in progress), October 2006.

Appendix A.  Non-Normative RELAX NG Schema in XML Syntax

   <?xml version="1.0" encoding="UTF-8"?>
   <grammar ns="urn:ietf:params:xml:ns:lost1"
           xmlns="http://relaxng.org/ns/structure/1.0"
           xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
           datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

           <start>
       <a:documentation>
         Location-to-Service Translation Protocol (LoST)

         A LoST XML instance has three request types, each with
         a cooresponding response type: find service, list services,
         and get service boundary.
       </a:documentation>
       <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" />
       </choice>
           </start>

     <div>
       <a:documentation>
         The queries.
       </a:documentation>

       <define name="findService">
         <element name="findService">
           <oneOrMore>
             <element name="location">
               <ref name="locationInformation" />
             </element>
           </oneOrMore>
           <ref name="query" name="commonRequestPattern" />
           <optional>
             <attribute name="include">
               <list>
                 <zeroOrMore> name="validateLocation">
               <data type="boolean" />
               <a:defaultValue>false</a:defaultValue>
             </attribute>
           </optional>
           <optional>
             <attribute name="serviceBoundary">
               <choice>
                     <value>uri</value>
                     <value>serviceNumber</value>
                     <value>displayName</value>
                     <value>service</value>
                     <value>valid</value>
                     <value>invalid</value>
                     <value>unchecked</value>
                     <value>serviceBoundary</value>
                     <value>serviceBoundaryReference</value>
                 <value>reference</value>
                 <value>value</value>
               </choice>
                 </zeroOrMore>
               </list>
               <a:defaultValue>uri serviceNumber</a:defaultValue>
               <a:defaultValue>reference</a:defaultValue>
             </attribute>
           </optional>
           <optional>
             <attribute name="recursive">
               <data type="boolean" />
                 <a:defaultValue>true</a:defaultValue>
             </attribute>
           </optional>
         </element>
       </define>

       <define name="listServices">
         <element name="listServices">
           <ref name="query" name="commonRequestPattern" />
         </element>
       </define>

       <define name="listServicesByLocation">
         <element name="listServicesByLocation">
           <zeroOrMore>
             <element name="location">
               <ref name="locationInformation" />
             </element>
           </zeroOrMore>
           <ref name="commonRequestPattern" />
           <optional>
             <attribute name="recursive">
               <data type="boolean" />
               <a:defaultValue>true</a:defaultValue>
             </attribute>
           </optional>
         </element>
       </define>

       <define name="getServiceBoundary">
         <element name="getServiceBoundary">
           <ref name="serviceBoundaryKey" />
           <ref name="extensionPoint" />
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
         The responses.
       </a:documentation>

       <define name="findServiceResponse">
         <element name="findServiceResponse "> name="findServiceResponse">
           <oneOrMore>
             <ref name="via" name="mapping" />
           <choice>
             <group>
               <optional>
                 <ref name="locationProfileError"/>
               </optional>
           </oneOrMore>
           <optional>
             <ref name="serviceSubstitution"/>
               </optional>
               <ref name="serviceResult" name="locationValidation" />
             </group>
             <ref name="badRequest"/>
             <ref name="internalError"/>
             <ref name="forbidden"/>
             <ref name="notFound"/>
             <ref name="serviceNotImplemented"/>
             <ref name="serverTimeout"/>
             <ref name="serverError"/>
             <ref name="movedPermenantly"/>
             <ref name="movedTemporarily"/>
             <ref name="iterativeSearchExhausted"/>
           </choice>
           </optional>
           <ref name="extensionPoint" name="commonResponsePattern" />
         </element>
       </define>

       <define name="listServicesResponse">
         <element name="listServicesResponse">
           <ref name="via" name="serviceList" />
           <choice>
             <group>
               <optional>
           <ref name="locationProfileError"/>
               </optional>
               <element name="serviceList">
                 <list>
                   <zeroOrMore>
                     <data type="anyURI" name="commonResponsePattern" />
                   </zeroOrMore>
                 </list>
         </element>
             </group>
           </choice>
       </define>

       <define name="listServicesByLocationResponse">
         <element name="listServicesByLocationResponse">
           <ref name="extensionPoint" name="serviceList" />
           <ref name="commonResponsePattern" />
         </element>
       </define>

       <define name="getServiceBoundaryResponse">
         <element name="getServiceBoundaryResponse">
           <choice>
             <group>
           <ref name="serviceBoundary"/>
             </group>
             <ref name="badRequest"/>
             <ref name="internalError"/>
           <ref name="forbidden"/>
             <ref name="notFound"/>
           </choice>
           <ref name="extensionPoint" name="commonResponsePattern" />
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
         A pattern common to some of the queries.
       </a:documentation>

       <define name="query">
         <oneOrMore>
           <element name="location"> name="commonRequestPattern">
         <ref name="locationInformation" name="service" />
           </element>
         </oneOrMore>
         <optional>
           <element name="service">
             <data type="anyURI"/>
           </element>
         </optional>
         <ref name="extensionPoint" />
         <optional>
           <attribute name="recursive">
             <data type="boolean"
       </define>
     </div>

     <div>
       <a:documentation>
         A pattern common to responses.
       </a:documentation>

       <define name="commonResponsePattern">
         <zeroOrMore>
           <ref name="warnings" />
         </zeroOrMore>
         <ref name="path" />
         <ref name="extensionPoint" />
               <a:defaultValue>true</a:defaultValue>
           </attribute>
         </optional>
       </define>
     </div>

     <div>
       <a:documentation>
         Location Information
       </a:documentation>

       <define name="locationInformation">
         <oneOrMore>
           <ref name="extensionPoint"/>
         </oneOrMore>
         <attribute name="profile">
           <data type="anyURI" type="NMTOKEN" />
         </attribute>
       </define>
     </div>

     <div>
       <a:documentation>
         Service Boundary
       </a:documentation>

       <define name="serviceBoundary">
         <oneOrMore>
           <element name="serviceBoundary">
             <ref name="locationInformation" />
           </element>
         </oneOrMore>
       </define>
     </div>

     <div>
       <a:documentation>
         Service Boundary Key Reference
       </a:documentation>

       <define name="serviceBoundaryReference">

         <element name="serviceBoundaryReference">
           <ref name="source" />
           <ref name="serviceBoundaryKey" />
           <ref name="extensionPoint" />
         </element>
       </define>

       <define name="serviceBoundaryKey">
         <attribute name="key">
           <data type="string">
             <param name="pattern">[a-zA-Z0-9/+=]+</param>
           </data> type="token" />
         </attribute>
       </define>

     </div>

     <div>
       <a:documentation>
         Via
         Path -
         Contains a list of via elements -
         places through which information flowed
       </a:documentation>

       <define name="via"> name="path">
         <element name="path">
           <zeroOrMore>
             <element name="via">
             <data type="anyURI"/>
               <ref name="source" />
               <ref name="extensionPoint" />
             </element>
           </zeroOrMore>
         </element>
       </define>
     </div>

     <div>
       <a:documentation>
         Time-to-live
         Expires pattern
       </a:documentation>

       <define name="timeToLive"> name="expires">
         <attribute name="timeToLive"> name="expires">
           <data type="positiveInteger"/> type="dateTime"/>
         </attribute>
       </define>
     </div>

     <div>
       <a:documentation>
         A QName list
       </a:documentation>

       <define name="qnameList">
         <list>
           <zeroOrMore>
             <data type="QName"/>
           </zeroOrMore>
         </list>
       </define>
     </div>

     <div>
       <a:documentation>
         A location-to-service result. mapping.
       </a:documentation>

       <define name="serviceResult">
         <optional> name="mapping">
         <element name="mapping">
           <zeroOrMore>
             <element name="displayName">
               <data type="string"/>
               <attribute name="xml:lang">
                 <data type="language"/>
               </attribute>
             </element>
         </optional>
         <optional>
           <element name="service">
             <data type="anyURI"/>
           </element>
         </optional>
           </zeroOrMore>
           <ref name="service" />
           <optional>
             <choice>
               <ref name="serviceBoundary"/>
             <element name="serviceBoundaryReference">
               <ref name="serviceBoundaryKey"/>
             </element> name="serviceBoundaryReference"/>
             </choice>
           </optional>
           <zeroOrMore>
             <element name="uri">
               <data type="anyURI"/>
             </element>
           </zeroOrMore>
           <optional>
             <element name="serviceNumber">
               <data type="string">
                 <param name="pattern">[0-9]+</param> name="pattern">[0-9*#]+</param>
               </data>
             </element>
           </optional>
           <ref name="extensionPoint"/>
           <ref name="expires"/>
           <attribute name="lastUpdated">
             <data type="dateTime"/>
           </attribute>
           <ref name="source" />
           <attribute name="sourceId">
             <data type="token" />
           </attribute>
           <attribute name="version">
             <data type="positiveInteger" />
           </attribute>
           <ref name="message"/>
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
         Location validation
       </a:documentation>

       <define name="locationValidation">
         <element name="locationValidation">
           <optional>
             <element name="valid">
               <ref name="qnameList" />
             </element>
           </optional>
           <optional>
             <element name="invalid">
               <ref name="qnameList" />
             </element>
           </optional>
           <optional>
             <element name="unchecked">
               <ref name="qnameList" />
             </element>
           </optional>
           <ref name="extensionPoint"/>
         </element>
       </define>
     </div>

     <div>
       <a:documentation>
         Errors and Warnings Container.
       </a:documentation>

       <define name="errorContainer">
         <interleave>
           <optional>
             <ref name="timeToLive"/> name="badRequest" />
           </optional>
           <optional>
             <ref name="message"/> name="internalError" />
           </optional>
           <optional>
             <ref name="serviceSubstitution" />
           </optional>
           <optional>
             <ref name="forbidden" />
           </optional>
           <optional>
             <ref name="notFound" />
           </optional>
           <optional>
             <ref name="loop" />
           </optional>
           <optional>
             <ref name="serviceNotImplemented" />
           </optional>
           <optional>
             <ref name="serverTimeout" />
           </optional>
           <optional>
             <ref name="serverError" />
           </optional>
           <optional>
             <ref name="locationProfileUnrecognized" />
           </optional>
         </interleave>
         <ref name="extensionPoint" />
         <ref name="source" />
       </define>
       <define name="errors">
         <element name="errors">
           <ref name="errorContainer" />
         </element>
       </define>

       <define name="warnings">
         <element name="warnings">
           <ref name="errorContainer" />
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
         Basic Errors
       </a:documentation>

       <define name="error"> name="basicError">
         <a:documentation>
           Error pattern.
         </a:documentation>
         <ref name="message"/>
         <ref name="extensionPoint" />
       </define>

       <define name="badRequest">
         <element name="badRequest">
           <ref name="error"/> name="basicError"/>
         </element>
       </define>

       <define name="internalError">
         <element name="internalError">
           <ref name="error"/> name="basicError"/>
         </element>
       </define>

       <define name="serviceSubstitution">
         <element name="serviceSubstitution">
           <ref name="error"/> name="basicError"/>
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
         Recursion Errors.
       </a:documentation>

       <define name="recursionError">
         <a:documentation>
           Recursion error.
         </a:documentation>
         <optional>
           <attribute name="failedReferral">
             <data type="anyURI"/>
           </attribute>
         </optional>
         <optional>
           <choice>
             <ref name="findService" />
             <ref name="listServices" />
             <ref name="getServiceBoundary" />
           </choice>
         </optional>
         <ref name="error"/>
       </define>

       <define name="forbidden">
         <element name="forbidden">
           <ref name="recursionError"/> name="basicError"/>
         </element>
         <ref name="timeToLive"/>
       </define>

       <define name="notFound">
         <element name="notFound">
           <ref name="recursionError"/> name="basicError"/>
         </element>
       </define>

       <define name="loop">
         <element name="loop">
           <ref name="timeToLive"/> name="basicError" />
         </element>
       </define>

       <define name="serviceNotImplemented">
         <element name="serviceNotImplemented">
           <ref name="recursionError"/> name="basicError"/>
         </element>
         <ref name="timeToLive"/>
       </define>

       <define name="serverTimeout">
         <element name="serverTimeout">
           <ref name="recursionError"/> name="basicError"/>
         </element>
         <ref name="timeToLive"/>
       </define>

       <define name="serverError">
         <element name="serverError">
           <ref name="recursionError"/> name="basicError"/>
         </element>
         <ref name="timeToLive"/>
       </define>

       <define name="locationProfileError"> name="locationProfileUnrecognized">
         <element name="locationProfileError"> name="locationProfileUnrecognized">
           <attribute name="unsupportedProfiles">
             <list>
               <zeroOrMore>
             <data type="anyURI"/>
               </zeroOrMore>
             </list> type="NMTOKENS" />
           </attribute>
           <ref name="recursionError"/> name="basicError"/>
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
         Redirects.
         Redirect.
       </a:documentation>
       <define name="redirect">
         <a:documentation>
           Redirect pattern
         </a:documentation>
         <attribute
         <element name="redirect">
           <attribute name="target">
             <data type="anyURI"/> type="anyURI" />
           </attribute>
           <ref name="error"/>
       </define>

       <define name="movedPermenantly">
         <element name="movedPermanently">
           <ref name="redirect"/>
         </element>
       </define>

       <define name="movedTemporarily">
         <element name="movedTemporarily">
           <ref name="redirect"/>
         </element>
         <ref name="timeToLive" name="source" />
       </define>

       <define name="iterativeSearchExhausted">
         <element name="iterativeSearchExhausted">
           <ref name="redirect"/>
         </element> name="message" />
           <ref name="timeToLive" name="extensionPoint" />
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
         Message pattern.
         Some common patterns.
       </a:documentation>

       <define name="message">
         <optional>
           <group>
             <attribute name="message">
               <data type="string"/>
             </attribute>
             <attribute name="xml:lang">
               <data type="language"/>
             </attribute>
           </group>
         </optional>
       </define>

       <define name="service">
         <optional>
           <element name="service">
             <data type="anyURI"/>
           </element>
         </optional>
       </define>

       <define name="source">
         <attribute name="source">
           <data type="anyURI" />
         </attribute>
       </define>
       <define name="serviceList" >
         <element name="serviceList">
           <list>
             <zeroOrMore>
               <data type="anyURI" />
             </zeroOrMore>
           </list>
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
         Patterns for inclusion of elements from schemas in
         other namespaces.
       </a:documentation>

       <define name="notLost">
         <a:documentation>
           Any element not in the LoST namespace.
         </a:documentation>
         <element>
           <anyName>
             <except>
               <nsName ns="urn:ietf:params:xml:ns:lost1"/>
               <nsName/>
             </except>
           </anyName>
           <ref name="anyElement"/>
         </element>
       </define>

       <define name="anyElement">
         <a:documentation>
           A wildcard pattern for including any element
           from any other namespace.
         </a:documentation>
         <zeroOrMore>
           <choice>
             <element>
               <anyName/>
               <ref name="anyElement"/>
             </element>
             <attribute>
               <anyName/>
             </attribute>
             <text/>
           </choice>
         </zeroOrMore>
       </define>

       <define name="extensionPoint">
         <a:documentation>
           A point where future extensions
           (elements from other namespaces)
           can be added.
         </a:documentation>
         <zeroOrMore>
           <ref name="notLost" />
         </zeroOrMore>
       </define>

       <define name="point2d">
         <a:documentation>
           A 2D point from GML.
         </a:documentation>
         <element name="position" name="Point" ns="http://www.opengis.net/gml">
           <element name="Point">
           <attribute name="srsName">
               <value>urn:ogc:def:crs:EPSG:4326</value>
             <value>urn:ogc:def:crs:EPSG::4326</value>
           </attribute>
             <element name="pos">
               <text/>
             </element>
           <ref name="pos"/>
         </element>
       </define>

       <define name="pos">
         <a:documentation>
           A GML position
         </a:documentation>
         <element name="pos" ns="http://www.opengis.net/gml">
           <list>
             <data type="double"/>
           </list>
         </element>
       </define>

       <define name="linearRing">
         <a:documentation>
           A Linear Ring from GML.
         </a:documentation>
         <element name="LinearRing"
           ns="http://www.opengis.net/gml">
           <element name="pos">
             <text/>
           </element>
           <ref name="pos"/>
           <ref name="pos"/>
           <ref name="pos"/>
           <oneOrMore>
             <ref name="pos"/>
           </oneOrMore>
         </element>
       </define>

       <define name="polygon">
         <a:documentation>
           A Polygon from GML.
         </a:documentation>
         <element name="Polygon"
           ns="http://www.opengis.net/gml">
           <attribute name="srsName">
             <value>urn:ogc:def:crs:EPSG:4979</value>
             <value>urn:ogc:def:crs:EPSG::4326</value>
           </attribute>
           <element name="exterior">
             <ref name="linearRing"/>
           </element>
           <zeroOrMore>
             <element name="interior">
               <ref name="linearRing"/>
             </element>
           </zeroOrMore>
         </element>
       </define>

     </div>

   </grammar>

                                 Figure 24

Authors' Addresses

   Ted Hardie
   Qualcomm, Inc.

   Email: hardie@qualcomm.com

   Andrew Newton
   SunRocket
   8045 Leesburg Pike, Suite 300
   Vienna, VA  22182
   US

   Phone: +1 703 636 0852
   Email: andy@hxr.us

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7004
   Email: hgs+ecrit@cs.columbia.edu
   URI:   http://www.cs.columbia.edu

   Hannes Tschofenig
   Siemens Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Phone: +49 89 636 40390
   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com

Full Copyright Statement

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).