Network Working Group                                          T. Hardie
Internet-Draft                                            Qualcomm, Inc.
Intended status: Standards Track                               A. Newton
Expires: March 8, April 25, 2007                                        SunRocket
                                                          H. Schulzrinne
                                                             Columbia U.
                                                           H. Tschofenig
                                                                 Siemens
                                                       September 4,
                                                        October 22, 2006

            LoST: A Location-to-Service Translation Protocol
                      draft-ietf-ecrit-lost-01.txt
                      draft-ietf-ecrit-lost-02.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 March 8, April 25, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes an XML-based protocol for mapping service
   identifiers and geospatial 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.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  6
   3.  Usage  . . .  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Resolving Service URNs Using LoST  .  Overview of Protocol Usage . . . . . . . . . . . . .  8
   5.  Query . . . . .  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.1.  Location Information Element . . . . . . . . . . . 10
     6.2.  Examples . . . .  9
     5.2.  Service Element . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  Validate Attribute 10
       6.2.1.  Example Using Geodetic Coordinates . . . . . . . . . . 10
       6.2.2.  Civic Address Mapping Example  . . . . . . . . . .  9
     5.4.  Query Message Examples . . 11
     6.3.  Components of <findService> Request  . . . . . . . . . . . 13
       6.3.1.  The <location> Element . . . . .  9
   6.  Response . . . . . . . . . . . 13
       6.3.2.  The <service> Element  . . . . . . . . . . . . . . . . 11
     6.1.  Uniform Resource Identifiers (URI) Element 13
       6.3.3.  Recursion or Redirection . . . . . . . . 11
     6.2.  Display Name Element . . . . . . . 13
       6.3.4.  Configuring the Response . . . . . . . . . . . . 11
     6.3.  Service Element . . . 14
     6.4.  Components of the Mapping Response
           <findServiceResponse>  . . . . . . . . . . . . . . . . . . 11
     6.4.  ServiceBoundary 16
       6.4.1.  Source of Response:  <via> Element . . . . . . . . . . 16
       6.4.2.  Service URLs: the <uri> Element  . . . . . . . 12
     6.5.  ServiceNumber Element  . . . . . 16
       6.4.3.  Describing the Service with the <displayName>
               Element  . . . . . . . . . . . . . 12
     6.6.  TimeToLive Attribute . . . . . . . . . . 17
       6.4.4.  Approximating Services:  the <service> Element . . . . 17
       6.4.5.  Defining the Service Region with the
               <serviceBoundary> Element  . . . . . 12
     6.7.  Validation Element . . . . . . . . . 17
       6.4.6.  Service Boundaries by Reference: the
               <serviceBoundaryReference> Element . . . . . . . . . . 17
       6.4.7.  The Service Number . 12
     6.8.  Response Message Examples . . . . . . . . . . . . . . . . 12
   7.  List Services Query and Response . 18
       6.4.8.  Civic Address Validation . . . . . . . . . . . . . . 15
     7.1.  List Service Query . 18
       6.4.9.  Validity: The 'timeToLive' Attribute . . . . . . . . . 18
   7.  Retrieving the Service Boundary via <getServiceBoundary> . . . 19
   8.  List Services: <listServices>  . . . . . . . 15
     7.2.  List Service Response . . . . . . . . . 21
   9.  Location Profiles  . . . . . . . . . 15
   8.  Status Code Definitions . . . . . . . . . . . . . 23
     9.1.  Location Profile Usage . . . . . . 17
     8.1.  Informational 1xx . . . . . . . . . . . . 23
     9.2.  Two Dimensional Geodetic Profile . . . . . . . . 17
     8.2.  Successful 2xx . . . . . 26
     9.3.  Basic Civic Profile  . . . . . . . . . . . . . . . . . 17
       8.2.1.  200 OK . . 26
   10. Error Handling . . . . . . . . . . . . . . . . . . . . . . 17
       8.2.2.  201 Service Substitution . . 27
     10.1. Basic Errors . . . . . . . . . . . . . 17
     8.3.  Redirection 3xx . . . . . . . . . . 27
     10.2. Response Errors  . . . . . . . . . . . 17
       8.3.1.  301 Move Permanently . . . . . . . . . . 27
     10.3. Redirects  . . . . . . . 17
       8.3.2.  302 Moved Temporarily . . . . . . . . . . . . . . . . 18
       8.3.3.  Example . 28
   11. LoST Transport . . . . . . . . . . . . . . . . . . . . . . 18
     8.4.  Client Error 4xx . . 29
   12. Relax NG Schema  . . . . . . . . . . . . . . . . . . . 18
       8.4.1.  400 Bad Request . . . . 30
   13. Internationalization Considerations  . . . . . . . . . . . . . 37
   14. IANA Considerations  . . 18
       8.4.2.  403 Forbidden . . . . . . . . . . . . . . . . . . . 38
     14.1. U-NAPTR Registrations  . 18
       8.4.3.  404 Not Found . . . . . . . . . . . . . . . . . 38
     14.2. Content-type registration for 'application/lost+xml' . . . 18
       8.4.4.  414 Location Error 38
     14.3. LoST Relax NG Schema Registration  . . . . . . . . . . . . 40
     14.4. LoST Namespace Registration  . . . . . . 18
       8.4.5.  Example . . . . . . . . . 40
     14.5. Registration Template  . . . . . . . . . . . . . . 18
     8.5.  Server Error 5xx . . . . 41
     14.6. LoST Location Profile Registry . . . . . . . . . . . . . . 42
   15. Security Considerations  . . . 20
       8.5.1.  500 Server Internal Error  . . . . . . . . . . . . . . 20
       8.5.2.  501 Service Not Implemented  . . . . . . . . . . . . . 20
       8.5.3.  504 Server Time-Out  . . . . . . . . . . . . . . . . . 21
       8.5.4.  Example . 43
   16. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 21
   9.  LoST Transport . 44
   17. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . 22
   10. LoST Uniform Resource Locators . . 45
   18. References . . . . . . . . . . . . . . 23
   11. Example . . . . . . . . . . . . 46
     18.1. Normative References . . . . . . . . . . . . . . . 24
   12. Deployment Methods . . . . 46
     18.2. Informative References . . . . . . . . . . . . . . . . . . 26
   13. Relax 47
   Appendix A.  Non-Normative RELAX NG Schema in XML Syntax . . . . . 48
   Authors' Addresses . . . . . . . . . . . . . . . . . . 28
   14. Internationalization Considerations  . . . . . . . . . . . . . 33
   15. IANA Considerations  . . . . . . . . . . . 61
   Intellectual Property and Copyright Statements . . . . . . . . . . 34
     15.1. Content-type registration 62

1.  Introduction

   This document describes a protocol for 'application/lost+xml' . . . 34
     15.2. mapping a service identifier
   [10] and location information compatible with PIDF-LO [8] to one or
   more service contact URIs.  Example contact URI schemes include sip
   [14], xmpp [15], and tel [16].  While the initial focus is on
   providing mapping functions for emergency services, it is likely that
   the protocol is applicable to any service URN.  For example, in the
   United States, the "2-1-1" and "3-1-1" services follow a similar
   location-to-service behavior as emergency services.

   This document names this protocol "LoST", for Location-to-Service
   Translation.  LoST Relax NG Schema Registration  . . . . . . . . . . . . 35
     15.3. Satisfies the requirements [18] for mapping
   protocols.  LoST Namespace Registration  . . . . . . . . . . . . . . . 36
     15.4. Registration Template  . . . . . . . . . . . . . . . . . . 36
   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 38
   17. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 39
   18. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 40
   19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
     19.1. Normative References . . . . . . . . . . . . . . . . . . . 41
     19.2. Informative References . . . . . . . . . . . . . . . . . . 42
   Appendix A.  Non-Normative RELAX NG Schema provides a number of operations, centered around
   mapping locations and service URNs to URIs 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.  LoST indicates errors in XML Syntax . . . . . 43
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
   Intellectual Property
   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, LoST caches individual mappings and indicates the region
   for which the same answer would be returned ("service region").

   As currently defined, 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 Copyright Statements . . . . . . . . . . 52

1.  Introduction

   This document describes a protocol for the overall
   mapping server architecture are described in a service identifier
   [6] and separate document
   [19].

   The query message carries location information compatible with PIDF-LO [11] 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 such as hints about the service contact URIs.  Example contact URI schemes include sip,
   xmpp, 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).  In
   addition to the mapping function described in Section 6, the protocol
   also allows to retrieve the service boundary Section 7 and tel.  While to list
   the initial focus services available for a particular location Section 8.

2.  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 on providing prepended with "C:" and
   the XML sent by the server is prepended with "S:".

4.  Overview of Protocol Usage

   The client may perform the mapping
   functions at any time.  Among the common
   triggers for emergency services, 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 likely that outside the bounds of the protocol is
   applicable to any service URN.  For example, region
       returned in the United States,
   the "2-1-1" and "3-1-1" services follow an earlier LoST query.

   3.  When cached mapping information has expired.

   4.  When invoking a similar location-to-service
   behavior as emergency services.

   This document names this protocol usage "LoST" particular service.  At that time, a client may
       omit requests for Location-to-
   Service Translation Protocol.  The features of LoST are:

   o  Supports queries using civic as well as geospatial location service boundaries or other auxiliary
       information.

   o  Support for recursive and iterative resolution.

   o  Support for address validation.

   o

   A hierarchical deployment of mapping servers service-specific BCP such as [20] governs whether a client is independent of
      civic location labels.

   o  Indication of errors in
   expected to invoke the location data mapping service just before needing the
   service or whether to facilitate debugging
      and proper user feedback while simultaneously providing best-
      effort answers.

   o  Mapping can be based rely on either civic cached answers.  Cache entries expire
   according to their time-to-live value (see Section 6.4.9, or geospatial location
      information, with uniform protocol treatment they
   become invalid if the caller's device moves beyond the boundaries of both.

   o  Support for overlapping service regions.

   o  Satisfies
   the requirements [5] for mapping protocols.

   o  Minimizes round trips by caching individual mappings service region.

5.  LoST Uniform Resource Locators and Their Resolution

   LoST servers are identified by
      supporting return LoST Uniform Resource Locators (URLs),
   which follow the format of coverage regions ("hinting").

   o  Facilitates reuse URLs defined in RFC 3986 [7], with the
   following ABNF:

      LoST-URI = "lost:" host

   'host' is defined in Section 3.2.2 of Transport Layer Security (TLS).

   This document focuses on 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 description of U-NAPTR specification described
   below to obtain a URI (indicating host and protocol) for the protocol between
   applicable LoST service.  In this document, only the
   mapping client (seeker or resolver) HTTP and HTTPS
   URL schemes are defined.  Note that the mapping server (resolver
   or other servers). HTTP URL can be any valid
   HTTP URL, including those containing path elements.

   The relationship between other functions, such as
   discovery of mapping servers, data replication and following two DNS entries resolve the overall
   mapping server architecture in general, will be described in a
   separate document. [20] is a first attempt LoST URL "lost:example.com"
   to describe such 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 mapping
   server architecture.

   The high-level protocol operation can be described as follows: Location
       Info      +----------+
       --------> |          | and Service   |  LoST    |
       URN       |  Server  |
       --------> |          |
                 +----------+

        Query

            URI +----------+
       <------- |          |
       Optional |  LoST    |
    Info (hints)|  Server  |
       <------- |          |
                +----------+

        Response

                            Figure 1: to URLs: <findService>

6.1.  Overview

   The <findService> query message carries location information and a service
   identifier encoded as a Uniform Resource Name (URN) (see [6]) from constitutes the LoST client to core of the LoST server.  The LoST server uses its
   database to map the input values
   functionality, mapping civic or geodetic locations to a Uniform Resource Identifiers
   (URI) URLs and returns it including optional information such as hints
   about
   associated data.  After giving an example, we enumerate the service boundary in a response message back to elements
   of the LoST
   client.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", query and "OPTIONAL" in this
   document are to be interpreted as described in [3].

3.  Usage response.

6.2.  Examples

6.2.1.  Example Using Geodetic Coordinates

   The client queries following is an example of mapping a server, indicating the desired service and
   location information.  If the query succeeds, the server returns to a
   result that includes one or more URIs location using
   geodetic coordinates, for reaching the appropriate service for the location indicated.  Depending on the query, associated with the
   result may contain a 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 boundary where 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: A <findService> Geodetic Query

   Given the same mapping query above, a server would
   apply, respond with a reference service, and
   information related to another that service.  In the example below, the
   server to which has mapped the location given by the client should send for a query, or an error messages indicating problems.  The combination
   of these components are left police
   service to the needs and policy of the
   jurisdiction where New York City Police Deparment, instructing the server is being operated.

   The client
   that it may perform the mapping at any time.  Among contact them via the common
   triggers for mapping are:

   1.  When URIs sip:nypd@example.com and
   xmpp:nypd@example.com.  The server has also given the client starts up and/or attaches to a new network
       location.

   2.  When
   geodetic, two-dimensional boundary for this service and time-to-live
   value of 3,600 seconds.  This instructs the client detects that if its
   location has changed
       sufficiently that it is outside the bounds of changes beyond the region returned
       in an earlier query.

   3.  When cached mapping information give service boundary or if 3,600 seconds
   has expired.

   4.  When calling for a particular service.  During such calls, a
       client may want elapsed, it would need to request a short response that contains only
       the 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 Example

   The following is an example of mapping data, omitting a service boundary information.

   Cached answers are expected to be used by clients only after failing to accomplish a location-to-URI mapping at call time.  Cache entries
   may expire according to their time-to-live value, or they may become
   invalid if the location of much
   like the caller's device moves outside example in Section 6.2.1, but using civic address location
   information.  In this example, the
   boundary limits of client requests the cache entry.  Boundaries for cache entries may
   be set in both geospatial and service
   associated with police (urn:service:sos.police) along with a specific
   civic terms.

4.  Resolving Service URNs Using LoST

   If address (house number 96 on a LoST URL contains street named Neu Perlach in
   Munich, Germany).

   <?xml version="1.0" encoding="UTF-8"?>
   <findService xmlns="urn:ietf:params:xml:ns:lost1"
     recursive="true"
     include="uri serviceNumber displayName serviceBoundary" >
     <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>
     </location>
     <service>urn:service:sos.police</service>
   </findService>

               Figure 4: A <findService> Civic Address Query

   Given the query above, a host name rather than an IP address, clients
   need to perform an U-NAPTR [17] lookup to obtain server would respond with a DNS A record service, and
   IP address.  These records map
   information related to that service.  In the 'host' part of example below, the LoST URL to one
   or more URLs indicating
   server has mapped the protocol location given by the client for a police
   service to carry the LoST request.  In
   this document, only M&#557;nchen Polizei-Abteilung, instructing the HTTP and HTTPS URL schemes are defined.  Note client
   that it may contact them via the HTTP URL can be any valid HTTP URL, including those
   containing path elements.

   Here is an example:

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

5.  Query

   LoST provides URIs sip:munich-police@example.com
   and xmpp:munich-police@example.com.  The server has also given the ability to use
   client a civic or geospatial location
   information in address boundary (the city of Munich) for this service
   and time-to-live value of 3,600 seconds.  This instructs the query message.  In addition to client
   that if its location
   information changes beyond the query also contains a give service identifier.  An
   optional parameter might furthermore request boundary (i.e.
   beyond the LoST server city of Munich) or if 3,600 seconds has elapsed, it would
   need to
   validate location requery for this information.

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

   LoST supports a

   The <findService> query using geospatial and civic communicates location information using the <findServiceByLocation> query.  Geospatial location
   information uses GML format [10] and civic location information
   utilizes the format defined in [16].  This document does not define one or more
   <location> elements, which MUST conform to a location formats.

5.2.  Service profile
   (Section 9).

6.3.2.  The <service> Element

   The type of service desired is specified by the <service> element.
   The (emergency)
   It contains service identifiers listed in URNs from the registry established with [6] will be used in this document.

   The <service> element is [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 mandatory element.  In case recursive query, a value of "false" an iterative query, with
   iterative being the database
   at default.  When the LoST server does not provided service for the specific
   geographical region cannot answer the LoST server has various choices with regard
   to
   query and the response:

   o  It can send query requested iterative resolution, it will return an
   <iterativeSearchExhausted> (Section 10.3) error response.

   o  It can map one service message with the LoST
   URI pointing to another one, if appropriate, and return a different service identifier as described in Section 6.3.

   o  It can populate LoST server that the URIs of one service to another service.

   The operation of LoST client should
   contact.  In recursive mode, the LoST server is largely initiates a policy issue.  No
   behavior is mandated in this document.  Guidelines for operating 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 the LoST server for emergency services is provided to provide in [21].

5.3.  Validate Attribute the mapping response.  The
   server ignores any element names that it does not understand.  The 'validate' attribute implements
   ordering of the tokens is immaterial.

   Among other features, it determines whether service boundaries are
   returned and whether they are returned by value or reference
   Section 7, and whether to validate civic locations.

   Address validation is requested by including the XML element names
   that provide address validation behavior described in [5].

5.4.  Query Message Examples

   This section shows an example of a query message providing geospatial the 'include' attribute, namely
   'valid', 'invalid' and civic location information.

   <?xml version="1.0" encoding="UTF-8"?>
   <findServiceByLocation
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"
     validate="false" operation="recursive">
     <locationInfo>
       <p2:Point id="point1" srsName="epsg:4326">
         <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates>
       </p2:Point>
     </locationInfo>
     <service>urn:service:sos.police</service>
   </findServiceByLocation>

   Figure 3: Query Message Example using Geospatial Location Information 'unchecked'.  The following example above shows a query using geospatial location information
   with no validation required and asking for the
   'urn:service:sos.police' service.
   demonstrates address validation.

   C: <?xml version="1.0" encoding="UTF-8"?>
   <findServiceByLocation
   C: <findService
   C:   xmlns="urn:ietf:params:xml:ns:lost1"
                          validate="false" operation="recursive">
     <locationInfo>
       <civicLocation>
   C:   recursive="true"
   C:   include="uri serviceNumber invalid valid unchecked">
   C:   <location
   C:     profile="urn:ietf:params:lost:location-profile:basic-civic">
   C:     <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:       <PC>81675</PC>
       </civicLocation>
     </locationInfo>
   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>
   </findServiceByLocation>
   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 4: Query Message Example using Civic Location Information

   The example above shows a query using a civic location in Munich
   asking for the 'urn:service:sos.police' service.  The query indicates
   that validation is not desired and 6: Address Validation Exchange

6.4.  Components of the query has to be executed
   recursively.

6. Mapping Response <findServiceResponse>

6.4.1.  Source of Response:  <via> Element

   A response message might either contain civic or geospatial location
   information depending on <findServiceResponse> indicates the type source of the query.  If the
   findServiceByLocation query message contained civic location
   information then the <serviceBoundary> response by
   including a <via> element of with a LoST URL as the response
   message will also first <via> element.
   Thus, each server "initials" its own response.  Thus, responses to
   iterative queries contain civic information.  If one <via> element, while responses to
   recursive queries may reach the original querier with multiple <via>
   elements, one for each server that was used in the resolution.  The
   following <findServiceResponse> example illustrates the use of <via>:

   <?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>
     <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 7: An Example of a Response Using <via>

   The example above indicates that the
   findServiceByLocation query message contained geospatial location
   information then this answer was given to the <serviceBoundary> element of
   responding server by the response
   message will contain a GML polygon.  More information about LoST server at esgw.uber-110.de.example,
   which got the
   <serviceBoundary> element can be found answer from the LoST server at Section 6.4.

6.1.  Uniform Resource Identifiers (URI) Element

   Each
   polizei.munchen.de.example.

6.4.2.  Service URLs: the <uri> element contains an appropriate contact URI for Element

   The response returns the service for which mapping was requested. URLs in one or more <uri> elements are of type
   xs:anyURI.  In elements.
   The URLs MUST be absolute URLs.

6.4.3.  Describing the emergency service context operators are strongly
   discouraged from using relative URIs, even though these are permitted
   by Service with the type.

6.2.  Display Name <displayName> Element

   Each

   The <displayName> element contains describes the service with a string that is
   suitable for
   display. <displayName> elements are of type "text" display to human users, annotated with the 'xml:lang'
   attribute that is suitable
   for internationalized human-readable text.

6.3.  Service Element

   The <service> element is an optional element contains a language tag to aid in the response message.
   The (emergency) service identifiers listed in rendering of
   text.

6.4.4.  Approximating Services:  the registry
   established with [6] will be used in this document. <service> Element

   If the service
   that was requested service, identified by the LoST client is service URN [10] in the
   <service> element in the request, does not available exist for a
   particular the location then
   indicated, the server MAY can either return an <serviceNotImplemented>
   (Section 10.2) error or can provide an alternate service.
   If it does so, it service that
   approximates the desired service for that location.  In the latter
   case, the server MUST indicate include a <service> element with the actual
   alternative service returned (i.e.,
   its URN.  The choice of service URN).  Alternatively, URN is left to local
   policy, but the LoST server MAY return an error alternate service should be able to satisfy the
   original service request.

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

   A response indicating that can indicate the region for which the service URL returned
   would be the same as in the requested actual query, the so-called service is not available.
   region.  The following example illustrates the main idea.  If there is a
   region that only understands the 'urn:service:sos' service and not
   'urn:service:sos.fire', 'urn:service:sos.ambulance', and
   'urn:service:sos.police'. region can be indicated by value or by reference
   Section 6.4.6.  If a LoST client asks for moves outside the
   'urn:service:sos.fire' service then the LoST server could, depending
   on the local policy at the LoST server, return:

   1.  'urn:service:sos', or

   2.  'urn:service:sos.fire' area, it MUST
   send a new query with the values of 'urn:service:sos' being
       populated its current location to 'urn:service:sos.fire', or
   3.  an error message

   In case of (1) the <service> element carries the obtain valid service
   data.  The service region is described by value of
   'urn:service:sos'.

6.4.  ServiceBoundary Element

   Each <serviceBoundary> element contains either in one or more civic
   location elements derived from the GeoPriv civic address schema or
   <serviceBoundary> elements, each formatted according to a
   GML-based polygon. different
   location profile.  The <serviceBoundary> element indicates where client only processes the same query would
   yield first element that
   it can understand according to its list of supported location
   profiles.  Thus, the elements are alternative descriptions of the
   same response, i.e., it provides service region, not additive geometries.

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

6.4.6.  Service Boundaries by Reference: the
   service boundary.

6.5.  ServiceNumber <serviceBoundaryReference>
        Element

   TBD: This element contains the (emergency)

   Since geodetic service number, which is a
   string boundaries may contain thousands of digits used points and
   thus be quite large, clients may opt to reach the (emergency) service.

6.6.  TimeToLive Attribute

   Each timeToLive attribute is conserve bandwidth and
   request a positive integer, expressing reference to the
   validity period service boundary instead of the response value
   described in seconds. Section 6.4.5.  The LoST client MUST NOT
   consider identifier of the service boundary
   is returned location current after in the <serviceBoundaryReference> element, along with a
   LoST URL identifying the expiration server from where it can be retrieved.  The
   actual value of the
   validity period.

6.7.  Validation Element service boundary is then retrieved with the
   getServiceBoundary (Section 7) request.

   The <validation> element contains identifier is a random token with at least 128 bits of entropy
   and can be assumed to be globally unique.  The identifier uniquely
   references a particular boundary; if the boundary changes, a string that is composed new
   identifier must be chosen.  Because of
   concatenated tokens separated by these properties, a whitespace.  These tokens refer to
   the civic location labels used in child elements client
   receiving a mapping response can simply check if it already has a
   copy of the
   <civicAddress> element from the request boundary with that have been recognized as
   valid by identifier.  If so, it can skip
   checking with the server.

   The following code snippet indicates that server whether the civic address labels
   'country', 'A1', 'A3', 'A6, 'PC' have boundary has been valided by updated.
   Since service boundaries are likely to remain unchanged for extended
   periods of time, possibly exceeding the LoST
   server.

            <validation>country A1 A3 A6 PC</validation>

6.8.  Response Message Examples

   This section shows an example normal lifetime of a query message providing geospatial
   and civic location information.

   <?xml version="1.0" encoding="UTF-8"?>
   <response
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"  >
     <result status="200" message="OK" xml:lang="en" timeToLive="1000">
       <displayName xml:lang="en">
         New York City Police Department
       </displayName>
       <service>urn:service:sos.police</service>
       <serviceBoundary>
         <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>
     </result>
   </response>

   Figure 6: Response Message Example using Geospatial Location Service
                              Boundary Hints

   This example shows a response with two URIs for the previously
   queried
   service URN.  Information about URL, this approach avoids refreshing the service boundary is
   provided by a GML polygon.  The <serviceNumber> element indicates information
   even if the
   valid cached service response has gotten stale.

6.4.7.  The Service Number

   The service number for is returned in the expressed location optional <serviceNumber>
   element.  It contains a string of digits, * and service URN.

   <?xml version="1.0" encoding="UTF-8"?>
   <response xmlns="urn:ietf:params:xml:ns:lost1">
     <result status="200" timeToLive="10000">
       <displayName xml:lang="de">Munich Police Department</displayName>
       <service>urn:service:sos.police</service>
       <serviceBoundary>
         <civicLocation>
           <country>Germany</country>
           <A1>Bavaria</A1>
           <A3>Munich</A3>
           <PC>81675</PC>
         </civicLocation>
       </serviceBoundary>
       <uri>sip:munich-police@example.com</uri>
       <uri>xmpp:munich-police@example.com</uri>
       <service-number>110</service-number>
     </result>
   </response>

    Figure 7: Response Message Example providing Civic Location Service
                              Boundary Hints

   This example shows # that a response user on a
   device with a 12-key dial pad could use to reach that returns two URIs (one for SIP particular
   service.

6.4.8.  Civic Address Validation

   A server can indicate in its response which civic address elements it
   has recognized as valid, which ones it has ignored and
   another one for XMPP), which ones it
   has checked and found to be invalid.  Each element contains a distring that indicates the valid distring
   for list of
   tokens separated by white space, enumerating the civic location provided in the query, a hint about the service
   boundary
   lables used in child elements of the <serviceBoundary> <civicAddress> element.  The
   <valid> element enumerates those civic address elements that have
   been recognized as valid by the LoST server and information about that have been used
   to determine the mapping.  The <unchecked> elements enumerates the
   validated
   civic address fields.  The timeToLive attribute indicates elements that the returned information can be cached for 10000 seconds server did not check and
   provides a *<displayName> element with additional, textual
   information about that were
   not used in determining the returned information.

7.  List Services Query and Response

7.1.  List Service Query

   This subsection describes a mechanism response.  The <invalid> element
   enumerate civic address elements that offers the LoST client server attempted to
   query for available service identifiers supported by check,
   but that did not match the LoST server. other civic address elements found in the
   <valid> list.

   The listServices query MUST carry example (Figure 6) indicates that the <locationInfo> tokens 'country', 'A1',
   'A3', and 'A6' have been validated by the
   <service> element.  The LoST server.  The server MUST return only immediate child
   elements of
   considered the service identifier specified postal code 81675 in the <service> <PC> element
   of the listServices query available as not valid for
   this location.

6.4.9.  Validity: The 'timeToLive' Attribute

   The timeToLive attribute contains the provided location
   information.

   <?xml version="1.0" encoding="UTF-8"?>
   <listServices
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"
     operation="false">

     <locationInfo>
       <p2:Point id="point1" srsName="epsg:4326">
         <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates>
       </p2:Point>
     </locationInfo>
     <service>urn:service:sos</service>
   </listServices>

                Figure 8: Example for a List Service Query

   This listService query aims to query number of seconds the immediate child elements 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.  Retrieving the 'urn:service:sos' URN.

7.2.  List Service Response

   This subsection describes Boundary via <getServiceBoundary>

   As discussed in Section 6.4.5, the <findService> response message can return
   a globally unique identifier that provides the LoST
   client with can be used to retrieve the list of immediate child service identifiers based on
   boundary, rather than returning the service identifier provided boundary by LoST value.  This is shown
   in the example in Figure 8.  The client with respect to can then retrieve the
   location information provided
   boundary using the <getServiceBoundary> request and obtains the
   boundary in the <getServiceBoundaryResponse>, illustrated in the listService query.

   The following
   example shows in Section 7.  The client issues the response request to the listServices query
   example of Figure 8 listing server
   identified in the available services offered by 'server' attribute of the
   LoST server starting with 'urn:service:sos.ambulance' and finishing
   with 'urn:service:sos.suicide'.
   <serviceBoundaryReference> element.

   C: <?xml version="1.0" encoding="UTF-8"?>
   <response xmlns="urn:ietf:params:xml:ns:lost1">
       <serviceList status="200" message="OK"
   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:   <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.809 -73.9612</p2:pos>
   C:     </p2:Point>
   C:   </location>
   C:   <service>urn:service:sos.police</service>
   C: </findService>

   S: <?xml version="1.0" encoding="UTF-8"?>
   S: <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
   S:   timeToLive="3600">
   S:   <displayName xml:lang="en">
         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>
   </response>
   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:   <uri>sip:nypd@example.com</uri>
   S:   <uri>xmpp:nypd@example.com</uri>
   S:   <serviceNumber>911</serviceNumber>
   S: </findServiceResponse>

           Figure 8: findService with Service Boundary Reference
   C: <?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: Example for the Response to Requesting a List Service Query

8.  Status Code Definitions

   Each response contains a <status> element that conveys a numeric
   status code and a reason phrase indicating the success or failure of
   the response.  The appearance of other elements in the response
   depends on the status code.  Hence, different elements are used for
   groups of status codes.

   Status codes always have three digits; the list of status codes is
   meant to be extensible by IANA registration and follows the general
   pattern of the Session Initiation Protocol (SIP) [22] and HTTP [14].
   The first digit indicates the type of response, Boundary with '2' signaling a
   successful request, '3' a redirection, '4' a getServiceBoundary

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

   <?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">
       <civicAddress
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>US</country>
         <A1>New York</A1>
         <A3>New York</A3>
       </civicAddress>
     </serviceBoundary>
   </getServiceBoundaryResponse>

            Figure 10: Civic Address Service Boundary Response

8.  List Services: <listServices>

   A LoST client behavior, and '5' can ask a LoST server failure. for the list of services it
   supports.  The <listServices> query contains one or more <location>
   elements, each from a different location profile (Section 9), and may
   contain the <service> element.  If used within HTTP, LoST also utilizes the normal HTTP status codes.
   However, query contains the HTTP request can succeed, while <service>
   element the LoST request caused
   an error.  All LoST status codes appear in HTTP 200 (OK) responses.
   For example, a LoST 404, 414 or 500 status would occur in an HTTP 200
   response.

   Temporary unavailability server returns only immediate child services of the
   queried service should be indicated by an
   HTTP 505 (Service Unavailable) status code.

   [Editor's Note: Does this make any sense or should all or some LoST
   errors occur in a non-200 HTTP response?]

8.1.  Informational 1xx

   This document does not define informational status codes.

8.2.  Successful 2xx

8.2.1.  200 OK

   The query completed successfully.

8.2.2.  201 Service Substitution

   The service requested is not that are available for the location requested,
   but provided location.  If the server is configured to provide a replacement service.

8.3.  Redirection 3xx

8.3.1.  301 Move Permanently

   The requested location
   <service> element is being mapped by a different server and absent, the LoST service returns all
   future requests top-level
   services available for that location (and locations in the service area)
   should be directed to that server.

8.3.2.  302 Moved Temporarily

   The requested provided location is being mapped by a different server, but
   future requests should continue that it knows about.

   A server responds to use this server.

8.3.3.  Example query with a <listServicesResponse>
   response.  This is an example response has may contain <via> elements
   (Section 6.4.1) and must contain a <serviceList> element, consisting
   of an error message with a 302 status code: whitespace-separated list of service URNs.  The query and
   response are illustrated in Figure 11.

   C: <?xml version="1.0" encoding="UTF-8"?>
   C: <listServices
   C:   xmlns="urn:ietf:params:xml:ns:lost1"
   C:   xmlns:p2="http://www.opengis.net/gml"
   C:   recursive="false">
   C:   <location
   C:     profile="urn:ietf:params:lost:location-profile:basic-civic">
   C:     <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: <?xml version="1.0" encoding="UTF-8"?>
   <response
   S: <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1">
     <redirect status="302"
       message="County-level routing"
       xml:lang="en"
       redirect="lost:co.lancaster.pa.us"
   </response>

8.4.  Client Error 4xx

8.4.1.  400 Bad Request

   The
   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>
                   Figure 11: ListService Query Example

9.  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 could or response contains
   location information in a format not be understood due to malformed syntax.

8.4.2.  403 Forbidden

   The by the server understood or
   client, respectively.  To achieve interoperability, LoST defines two
   must-implement baseline location profiles to define the request, but manner in
   which location information is refusing to fulfill it.
   Authorization will not help, transmitted and makes it possible to
   standardize other profiles in the request SHOULD NOT be repeated.

8.4.3.  404 Not Found future.  The server has definitive information that there is no service
   mapping two baseline profiles
   are:

   geodetic-2d:  a simple profile for the two-dimensional geodetic location specified.

8.4.4.  414 Location Error

   The
      information, described in Section 9.2);

   civic:  a profile consisting of civic address location provided does not exist information,
      described in Section 9.3.

   Requests and responses containing <location> or fields within the <serviceBoundary>
   elements MUST contain location information are contradictory.

8.4.5.  Example

   The first example shows an error message with a 414 status code that
   is attached to the response message indicating that there was a
   problem with the postal code:

   <?xml version="1.0" encoding="UTF-8"?>
   <response xmlns="urn:ietf:params:xml:ns:lost1">
     <result status="250" message="Default Route"
                          xml:lang="en" timeToLive="10000">
       <displayName xml:lang="en">
         New York City Police Department
       </displayName>
       <service>unknown</service>
       <serviceBoundary>
         <civicLocation>
           <country>US</country>
           <A1>New York</A1>
           <A3>New York</A3>
         </civicLocation>
       </serviceBoundary>
       <uri>sip:nypd@example.com</uri>
       <uri>xmpp:nypd@example.com</uri>
       <service-number>911</service-number>
     </result>
     <failure status="414" message="Address error" xml:lang="en">
       <cause name="PC"
         message="postal code is outside in exactly one of service boundary"
         xml:lang="en" />
     </failure>
   </response> the two
   baseline profiles, in addition to zero or more additional profiles.
   The second example shows an error message with ordering of location information indicates a 414 status code that
   is attached to preference on the response message indicating that there was a
   problem with
   part of the provided geospatial sender.

   Standards action may create other profiles.  A location information:

   <?xml version="1.0" encoding="UTF-8"?>
   <response
     xmlns="urn:ietf:params:xml:ns:lost1"
     xmlns:p2="http://www.opengis.net/gml"  >
     <result status="250" message="Default PSAP"
             xml:lang="en" timeToLive="1000">
       <displayName xml:lang="en">
         New York City Police Department
       </displayName>
       <service>urn:service:sos.police</service>
       <serviceBoundary>
         <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>
     </result>
     <failure status="414"
        message="Invalide Goegraphic Location" xml:lang="en">
       <cause name="p2:coordinates"
         message="invalid latitude" xml:lang="en" />
     </failure>
   </response>

8.5.  Server Error 5xx

8.5.1.  500 Server Internal Error profile MUST
   define:

   1.  The server encountered an unexpected condition that prevented token identifying it from
   fulfilling in the request. LoST location profile registry;

   2.  The client MAY retry formal definition of the request after
   several seconds.

8.5.2.  501 Service Not Implemented XML to be used in requests, i.e., an
       enumeration and definition of the XML child elements of the
       <location> element;

   3.  The server does not implement mapping for formal definition of the service requested and
   cannot provide XML to be used in responses, i.e.,
       an alternate service.

8.5.3.  504 Server Time-Out

   A server time-out occurs if enumeration and definition of the server contacted tries to recursively
   resolve XML child elements of the query, but cannot get an answer within
       the time limit set
   for <serviceBoundary> element;

   4.  The declaration of whether geodetic-2d or civic is to be used as
       the query.

8.5.4.  Example

   This baseline profile.  It is an example necessary to explicitly declare the
       baseline profile as future profiles may be combinations of
       geodetic and civic location information.

9.1.  Location Profile Usage

   A location profile is identified by a URN in the
   urn:ietf:params:lost:location-profile registry.  (Note that this is
   not an error message XML schema or namespace identifier.)  Clients send location
   information compliant with a 500 status code:

   <?xml version="1.0" encoding="UTF-8"?>
   <response xmlns="urn:ietf:params:xml:ns:lost1">
     <status code="500">Server failure</status>
   </response>

9.  LoST Transport location profile, and servers respond
   with location information compliant with that same location profile.

   When a LoST needs an underlying protocol transport mechanisms to carry
   requests client sends a request which provides location
   information, it contains one or more <location> elements.  Each of
   these elements contains location information compliant with a
   location profile and responses. specifies which profile has been used in the
   'profile' attribute.  This document defines allows the use of LoST over
   HTTP and HTTP-over-TLS; other mechanisms are left client to future
   documents.  The available transport mechanisms are indicated convey location
   information for multiple location profiles in the
   LoST U-NAPTR DNS resource record.  In protocols that support content
   type indication, LoST uses the media type application/lost+xml. same request.

   When using HTTP [14] and HTTP-over-TLS [15], a LoST requests use the
   HTTP POST method.  All HTTP responses are applicable.  The HTTP URL
   is derived from server sends a response which contains location
   information, it uses the LoST URL via U-NAPTR translation, as discussed in
   Section 4.

10.  LoST Uniform Resource Locators

   LoST Uniform Resource Locators (URLs) follow <serviceBoundary> elements much like the format of URLs
   defined
   client uses the <location> elements.  Each <serviceBoundary> element
   contains location information conformant to the location profile
   specified in RFC 3986 [9], the 'profile' attribute.  This allows the server to send
   location information compliant with multiple location profiles.

   Using the following ABNF:

      LoST-URI = "lost:" host

   'host' is location profiles defined in Section 3.2.2 of RFC 3986 [9].

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

11.  Example

   After performing link layer attachment this document, the following
   rules insure basic interoperatiblity between clients and end host performs stateful
   address autoconfiguration (in our example) using DHCP.  Then, DHCP
   provides servers:

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

   2.  If a client sends location as described information conformant to any location
       profile other than geodetic-2d or civic, it MUST also send, in [19].

      +--------+---------------+
      | CAtype | CAvalue       |
      +--------+---------------+
      | 0      | US            |
      | 1      | New York      |
      | 3      | New York      |
      | 6      | Broadway      |
      | 22     | Suite 75      |
      | 24     | 10027-0401    |
      +--------+---------------+

                 Figure 14: DHCP Civic Information Example

   Additionally, DHCP may provide
       the same request, location information about conformant to one of the
       baseline profiles.  Otherwise, the LoST server that
   can might not be contacted.  Alternatively, an additional step of indirection
   is possible, for example by having DHCP return able to
       understand the request.

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

   4.  A server ignores any location information using non-baseline
       profiles it does not understand.

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

   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 resolved able to one understand the request and provide an
   understandable response, though with location information that might
   not be as precise or more IP addresses hosting LoST servers.

   Both at attachment time expressive as desired.  This is possible because
   both Client X and call time, Server Y understand the baseline profile.  The
   following transaction, where the XML sent by the client places a LoST
   request, including its civic location is prepended
   with 'C:' and the desired service.  The
   request XML sent by the server is shown below: prepended with 'S:',
   demonstrates this:

   C: <?xml version="1.0" encoding="UTF-8"?>
   <findServiceByLocation
   C: <findService xmlns="urn:ietf:params:xml:ns:lost1"
                          validate="false" operation="recursive">
     <locationInfo>
       <civicLocation>
         <country>US</country>
         <A1>New York</A1>
         <A3>New York</A3>
         <A6>Broadway</A6>
         <LOC>Suite 75</LOC>
         <PC>10027-0401</PC>
       </civicLocation>
     </locationInfo>
   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:   <location
   C:     profile="
   C:       urn:ietf:params:lost:location-profile:uber-complex-3d">
   C:     <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
   C:        <p2:pos>37.775 -122.422 25</p2:pos>
   C:     </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:LinearRing>
   C:       </p2:exterior>
   C:     </p2:Polygon>
   C:   </location>
   C:   <service>urn:service:sos.police</service>
   </findServiceByLocation>

                              Mapping Request
   Since
   C: </findService>

   S: <?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:   <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:     <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:   <uri>sip:nypd@example.com</uri>
   S: </findServiceResponse>

     Figure 12: Example of a findServices query with baseline profile
                             interoperability

9.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 contacted LoST server has <location> element.  This is defined by the requested information
   available 'point2D'
   pattern in the following response is returned.  The <displayName>
   element indicates, as LoST schema (see Section 12).

   Servers use this profile by placing a human readable display string, that GML [13] <Polygon> element
   within the 'New
   York City Police Department' <serviceBoundary> element.  This is responsible for defined by the given
   geographical area.
   'polygon' pattern in the LoST schema (see Section 12).

9.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 URI allows by error-specific elements.  Depending on the user to start
   communication using SIP or XMPP.  The <validation>
   nature of the error, the error element indicates
   which parts may occur along with other
   response elements, indicating that the request was only partially
   satisfied and that not all information in the request was processed
   correctly.  Errors labeled as fatal means

10.1.  Basic Errors

   LoST defines a pattern for errors, defined as "errors" in the Relax
   NG schema.  This pattern defines a 'message' attribute containing
   human readable text and an 'xml:lang' attribute denoting the language
   of the civic address were matched successfully against human readable text.

   LoST defines the following elements as following this pattern:

   badRequest  The server could not parse or otherwise understand a
   database and represent
      request.  This is a known address.  Other parts of the address,
   here, the suite number, were ignored top-level element, and is returned if the
      server did not validated.  The
   <serviceBoundary> element indicates that all of New York City would
   result in understand the same response.  The <serviceNumber> outermost LoST XML element indicates
   that the service can be reached via
      identifying the emergency service number 911.

   <?xml version="1.0" encoding="UTF-8"?>
   <response xmlns="urn:ietf:params:xml:ns:lost1">
     <result status="200" message="OK" xml:lang="en" timeToLive="10000">
       <displayName xml:lang="en">
         New York City Police Department
       </displayName>
       <service>unknown</service>
       <serviceBoundary>
         <civicLocation>
           <country>US</country>
           <A1>New York</A1>
           <A3>New York</A3>
         </civicLocation>
       </serviceBoundary>
       <uri>sip:nypd@example.com</uri>
       <uri>xmpp:nypd@example.com</uri>
       <service-number>911</service-number>
     </result>
   </response>

                             Mapping Response

12.  Deployment Methods

   Because services for emergency contact resolution may differ
   depending on local or request.

   serviceSubstitution  The server substituted one service needs, this document only specifies the
   "wire format" for another.
      See Section 6.4.4.

10.2.  Response Errors

   LoST services and explicitly leaves open the
   possibility for many different types of deployment.

   For instance:

      During discovery, defines a client pattern for errors that may be directed to issue all queries to
      an generated by referrent
   LoST service completely authoritative for serves queried on behalf of seekers by a given jurisdiction.

      A client may be directed to issue queries to an resolving LoST server.
   This pattern builds on the basic errors pattern (Section 10.1).  It
   also provides the option of specifying the source server that
      acts using the
   'source' attribute, as a reflector.  In such a case, well as specifying the query that caused the
   error.

   LoST server analyzes defines the
      query following elements as following this pattern:

   forbidden  The server refused to send an answer.

   notFound  The server could not find an answer to determine the best query.

   serviceNotImplemented  The requested service is not implemented.

   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 an answer was received.

   serverError  An answer was received but it could not be parsed or
      otherwise understood.

   locationProfileError  A location profile in the query given is not
      recognized.  The element may also have an 'unsupportedProfiles'
      attribute, which to refer contains a whitespace separated list of profile
      URNs.  See Section 9.

10.3.  Redirects

   LoST defines a pattern for redirect responses.  This pattern builds
   on the basic error pattern (Section 10.1) and includes a 'url'
   attribute indicating the client.

      Or LoST URL that the client may should be directed to a server that performs further
      resolution on behalf of
   contacting next.

   Currently, LoST only defines the client.

   A <redirect> element along this
   pattern.

11.  LoST service may also be represented by multiple Transport

   LoST servers,
   either grouped together or at multiple network locations.  Using
   S-NAPTR [24], clients may be given a list of multiple servers needs an underlying protocol transport mechanisms to
   which queries can be sent for a single service.

   For instance, carry
   requests and responses.  This document defines the service at emergency.example.com may advertise use of LoST
   service at local1.emergency.example.com,
   local2.emergency.example.com, over
   HTTP and master.emergency.example.com.  Each
   server may given a different preference. 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 this case, 'local-1' protocols that support
   content type indication, LoST uses the media type application/
   lost+xml.

   When using HTTP [3] and
   'local-2' may be given a lower preference (more preferred) than
   'master', which might be a busier server or located further away.

   +-----------+             pref 10 +-----------+
   |           |-------------------->+           |
   |  client   |------               |  local-1  |
   |           |---   \              |           |
   +-----------+   \   \             +-----------+
                    \   \
                     \   \           +-----------+
                      \   \  pref 10 |           |
                       \   --------->|  local-2  |
                        \            |           |
                         \           +-----------+
                          \
                           \                           +-----------+
                            \                  pref 20 |           |
                             ------------------------->|  master   |
                                                       |           |
                                                       +-----------+

13. 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.  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 = "urn:ietf:params:xml:ns:lost1" "http://www.opengis.net/gml"
   namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
   namespace ns1 = "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
 namespace ns2 = "http://www.opengis.net/gml" "urn:ietf:params:xml:ns:lost1"

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

   ##
   ##       The queries.
   ##
   div {
     findService =
       element ns1:findService {
         query,
         attribute include {
           list {
             ("uri"
              | "serviceNumber"
              | "displayName"
              | "service"
              | "valid"
              | "invalid"
              | "unchecked"
              | "serviceBoundary"
              | "serviceBoundaryReference")*
           }
           >> a:defaultValue [ "uri serviceNumber" ]
         }?
       }
     listServices = element ns1:listServices { query }
     getServiceBoundary =
       element ns1:getServiceBoundary {
         serviceBoundaryKey, extensionPoint
       }
   }

   ##       and the response to these queries.
   ##
 start       The responses.
   ##
   div {
     findServiceResponse = findServiceByLocation
       element ns1:findServiceResponse {
         via,
         ((locationProfileError?, serviceSubstitution?, serviceResult)
          | listServices badRequest
          | response internalError
          | forbidden
          | notFound
          | serviceNotImplemented
          | serverTimeout
          | serverError
          | movedPermenantly
          | movedTemporarily
          | iterativeSearchExhausted),
         extensionPoint
       }
     listServicesResponse =
       element ns1:listServicesResponse {
         via,
         ((locationProfileError?,
           element ns1:serviceList {
             list { xsd:anyURI* }
           })),
         extensionPoint
       }
     getServiceBoundaryResponse =
       element ns1:getServiceBoundaryResponse {
         (serviceBoundary
          | badRequest
          | internalError
          | forbidden
          | notFound),
         extensionPoint
       }
   }

   ##
   ##       The       A pattern common to some of the queries.
   ##
   div {
   findServiceByLocation
     query =
       element findServiceByLocation ns1:location {
       query, locationInformation }+,
       element ns1:service { xsd:anyURI }?,
       extensionPoint,
       attribute validate recursive { xsd:boolean >> a:defaultValue [ "false" "true" ] }?
   }
   listServices

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

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

   ##
   ##               2xx responses.       Service Boundary Key
   ##
       (result
        | element serviceList
   div {
     serviceBoundaryKey =
       attribute key {
         xsd:string { pattern = "[a-zA-Z0-9/+=]+" }
       }
   }

   ##
   ##       Via - list of places through which information flowed
   ##
   div { xsd:anyURI* },
            status
          })?,
     via = element ns1:via { xsd:anyURI }*
   }

   ##
   ##             3xx, 4xx, and 4xx responses.       Time-to-live pattern
   ##
       ((error | redirect | failure)?),
       extensionPoint
   div {
     timeToLive = attribute timeToLive { xsd:positiveInteger }
   }

   ##
   ##       Query pattern.       A QName list
   ##
   div {
   query
     qnameList = list { xsd:QName* }
   }

   ##
   ##       A location-to-service result.
   ##
   div {
     serviceResult =
       element locationInfo ns1:displayName { anyElement* },
         xsd:string,
         attribute xml:lang { xsd:language }
       }?,
       element service ns1:service { xsd:anyURI },
     extensionPoint,
     [ a:defaultValue [ "recursive" ] ] attribute operation }?,
       (serviceBoundary
        | element ns1:serviceBoundaryReference { text }? serviceBoundaryKey })?,
       element ns1:uri { xsd:anyURI }*,
       element ns1:serviceNumber {
         xsd:string { pattern = "[0-9]+" }
       }?,
       element ns1:valid { qnameList }?,
       element ns1:invalid { qnameList }?,
       element ns1:unchecked { qnameList }?,
       extensionPoint,
       timeToLive,
       message
   }

   ##
   ##       A result.       Basic Errors
   ##
   div {

     ##
     ##         2xx response.         Error pattern.
     ##
   result
     error = message, extensionPoint
     badRequest = element result ns1:badRequest { error }
     internalError = element displayName ns1:internalError {
         xsd:string,
         attribute xml:lang error }
     serviceSubstitution = element ns1:serviceSubstitution { xsd:language error }
   }
   ##
   ##       Recursion Errors.
   ##
   div {

     ##
     ##         Recursion error.
     ##
     recursionError =
       attribute failedReferral { xsd:anyURI }?,
       (findService | listServices | getServiceBoundary)?,
       error
     forbidden =
       element service ns1:forbidden { xsd:anyURI recursionError },
       timeToLive
     notFound =
       element ns1:notFound { recursionError },
       timeToLive
     serviceNotImplemented =
       element serviceBoundary ns1:serviceNotImplemented {
         (civicLocation, polygon?) | (civicLocation?, polygon)
       }?, recursionError },
       timeToLive
     serverTimeout =
       element uri ns1:serverTimeout { xsd:anyURI }+, recursionError },
       timeToLive
     serverError =
       element serviceNumber {
         xsd:string ns1:serverError { pattern recursionError },
       timeToLive
     locationProfileError = "[0-9]+" }
       }?,
       element validation ns1:locationProfileError {
         attribute unsupportedProfiles {
           list { xsd:QName* xsd:anyURI* }
       }?,
       extensionPoint,
       attribute timeToLive { xsd:positiveInteger
         },
       status
         recursionError
       }
   }

   ##
   ##       Non-result responses.       Redirects.
   ##
   div {

     ##
     ##         5xx response.
   ##
   error = element error { status, extensionPoint }

   ##
   ##         3xx response.         Redirect pattern
     ##
     redirect =
     element redirect {
       status,
       attribute redirect { xsd:anyURI },
       extensionPoint
     }

   ##
   ##         4xx response.
   ##
   failure
       error
     movedPermenantly = element failure ns1:movedPermanently {
       status, redirect }
     movedTemporarily =
       element cause ns1:movedTemporarily {
         attribute name { xsd:QName redirect },
         attribute message
       timeToLive
     iterativeSearchExhausted =
       element ns1:iterativeSearchExhausted { xsd:string redirect },
         attribute xml:lang { xsd:language }
       }*,
       extensionPoint
     }
       timeToLive
   }

   ##
   ##       Status       Message pattern.
   ##
   div {
   status
     message =
     attribute status { xsd:positiveInteger },
     attribute extendedStatus { xsd:positiveInteger }?,
       (attribute message { xsd:string },
        attribute xml:lang { xsd:language })?
   }

   ##
   ##       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
       (element * {
       (attribute anyElement }
        | attribute * { text }
        | text
        | anyElement)*
     } text)*

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

     ##
     ##         A pattern to include the GEOPRIV civil location elements. 2D point from GML.
     ##
   civicAddress
     point2d =
       element ns1:* position {
       (attribute *
         element Point {
           attribute srsName { "urn:ogc:def:crs:EPSG:4326" },
           element pos { text }
        | text
        | anyElement)*
         }
       }

     ##
     ##         A definition of civic location Linear Ring from GEOPRIV. GML.
     ##
   civicLocation
     linearRing =
       element civicLocation LinearRing {
         element pos { civicAddress*, anyElement* text }
       }

     ##
     ##         A pattern to include GML elements. Polygon from GML.
     ##
   GML
     polygon =
       element ns2:* Polygon {
       (attribute *
         attribute srsName { text }
        | text
        | anyElement)*
     }
   polygon = "urn:ogc:def:crs:EPSG:4979" },
         element ns2:Polygon exterior {
       attribute * linearRing },
         element interior { text }*,
       GML linearRing }*
       }
   }

14.

13.  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 it is they are thus a complex type types designed
   for this purpose.

15.

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

15.1.

14.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.  Content-type registration for 'application/lost+xml'

   This specification requests the registration of a new MIME type
   according to the procedures of RFC 4288 [13] [9] and guidelines in RFC
   3023 [12]. [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 [12], [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>

15.2.

14.3.  LoST Relax NG Schema Registration

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

   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 13. 12.  Its first line is

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

      and its last line is

   }

15.3.

14.4.  LoST Namespace Registration

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

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

15.4.

14.5.  Registration Template

   This registration template is in accordance with [8]. [4].

   URL scheme name:

      lost

   URL scheme syntax:

      See Section 10 5

   Character encoding considerations:

      See Section 10 5

   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 16 15

   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>

16.

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

   civic:  Defined in TBD

15.  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
   authors RECOMMEND the use
   of channel channels security, such as TLS, with
   LoST. is RECOMMENDED.

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

17. [17].

16.  Acknowledgments

   [Editor's Note: Names need to be added here.  Forgot it...Sorry.]

18.

17.  Open Issues

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

19.

18.  References

19.1.

18.1.  Normative References

   [1]   World Wide Web Consortium, "XML Schema Part 2: Datatypes",
         W3C XML Schema, October 2000,
         <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.

   [2]   World Wide Web Consortium, "XML Schema Part 1: Structures",
         W3C XML Schema, October 2000,
         <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.

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

   [4]   Taylor, T., "Security Threats and Requirements for Emergency
         Call Marking

   [2]   Narten, T. and Mapping", draft-ietf-ecrit-security-threats-03
         (work in progress), July 2006.

   [5]   Schulzrinne, H. and R. Marshall, "Requirements Alvestrand, "Guidelines for Emergency
         Context Resolution with Internet Technologies",
         draft-ietf-ecrit-requirements-12 (work Writing an IANA
         Considerations Section in progress),
         August 2006.

   [6]   Schulzrinne, RFCs", BCP 26, RFC 2434,
         October 1998.

   [3]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., "A Uniform Resource Name (URN) for Services",
         draft-ietf-ecrit-service-urn-05 (work in progress),
         August 2006.

   [7]   Mealling, M., "The IETF XML Registry",
         draft-mealling-iana-xmlns-registry-05 (work in progress), Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 2003.

   [8] 1999.

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

   [9]

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

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

   [11]

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

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

   [13]

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

   [14]  Fielding, R., Gettys, J., Mogul, J., Frystyk,

   [10]  Schulzrinne, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

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

   [16] "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-02 draft-ietf-geopriv-revised-civic-lo-04 (work in
         progress), April September 2006.

   [17]

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

19.2.

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

18.2.  Informative References

   [18]

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

   [19]

   [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., "Dynamic Host Configuration Protocol (DHCPv4 H. and DHCPv6) Option R. Marshall, "Requirements for Civic  Addresses Configuration
         Information", draft-ietf-geopriv-dhcp-civil-09 Emergency
         Context Resolution with Internet Technologies",
         draft-ietf-ecrit-requirements-12 (work in progress), January
         August 2006.

   [20]

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

   [21]

   [20]  Rosen, B. and J. Polk, "Best Current Practice for
         Communications Services in support of Emergency Calling",
         draft-rosen-sos-phonebcp-01 (work in progress), June 2006.

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

   [23]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for Network  Address Translator (NAT) Traversal for
         Offer/Answer Protocols", draft-ietf-mmusic-ice-10
         draft-ietf-ecrit-phonebcp-00 (work in progress), August October 2006.

   [24]  Daigle, L. and A. Newton, "Domain-Based Application Service
         Location Using SRV RRs and the Dynamic Delegation Discovery
         Service (DDDS)", RFC 3958, January 2005.

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 "root" types:
        the findServiceByLocation query, the listServices query,
        and the request types, each with
         a cooresponding response to these type: find service, list services,
         and get service boundary.
       </a:documentation>
       <choice>
         <ref name="findService" />
         <ref name="listServices" />
         <ref name="getServiceBoundary" />
         <ref name="findServiceResponse" />
         <ref name="listServicesResponse" />
         <ref name="getServiceBoundaryResponse" />
       </choice>
     </start>

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

       <define name="findService">
         <element name="findService">
           <ref name="query" />
           <optional>
             <attribute name="include">
               <list>
                 <zeroOrMore>
                   <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>
                   </choice>
                 </zeroOrMore>
               </list>
               <a:defaultValue>uri serviceNumber</a:defaultValue>
             </attribute>
           </optional>
         </element>
       </define>

       <define name="listServices">
         <element name="listServices">
           <ref name="query" />
         </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 ">
           <ref name="via" />
           <choice>
             <group>
               <optional>
                 <ref name="locationProfileError"/>
               </optional>
               <optional>
                 <ref name="serviceSubstitution"/>
               </optional>
               <ref name="serviceResult" />
             </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="findServiceByLocation" name="movedTemporarily"/>
             <ref name="iterativeSearchExhausted"/>
           </choice>
           <ref name="extensionPoint" />
         </element>
       </define>

       <define name="listServicesResponse">
         <element name="listServicesResponse">
           <ref name="listServices" name="via" />
           <choice>
             <group>
               <optional>
                 <ref name="response" name="locationProfileError"/>
               </optional>
               <element name="serviceList">
                 <list>
                   <zeroOrMore>
                     <data type="anyURI" />
                   </zeroOrMore>
                 </list>
               </element>
             </group>
           </choice>
          </start>
           <ref name="extensionPoint" />
         </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" />
         </element>
       </define>
     </div>

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

       <define name="findServiceByLocation"> name="query">
         <oneOrMore>
           <element name="findServiceByLocation"> name="location">
             <ref name="query" name="locationInformation" />
           </element>
         </oneOrMore>
         <optional>
           <element name="service">
             <data type="anyURI"/>
           </element>
         </optional>
         <ref name="extensionPoint" />
         <optional>
           <attribute name="validate"> name="recursive">
             <data type="boolean" />
              <a:defaultValue>false</a:defaultValue>
               <a:defaultValue>true</a:defaultValue>
           </attribute>
         </optional>
        </element>
       </define>

     </div>

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

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

     <div>
       <a:documentation>
         Service Boundary
       </a:documentation>
       <define name="serviceBoundary">
         <oneOrMore>
           <element name="listServices"> name="serviceBoundary">
             <ref name="query" name="locationInformation" />
           </element>
         </oneOrMore>
       </define>
     </div>

     <div>
       <a:documentation>
        The response.
         Service Boundary Key
       </a:documentation>

       <define name="response">
        <element name="response">
          <optional>
            <choice> name="serviceBoundaryKey">
         <attribute name="key">
           <data type="string">
             <param name="pattern">[a-zA-Z0-9/+=]+</param>
           </data>
         </attribute>
       </define>
     </div>

     <div>
       <a:documentation>
                2xx responses.
         Via - list of places through which information flowed
       </a:documentation>
              <ref name="result" />

       <define name="via">
         <zeroOrMore>
           <element name="serviceList"> name="via">
             <data type="anyURI"/>
           </element>
         </zeroOrMore>
       </define>
     </div>

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

       <define name="timeToLive">
         <attribute name="timeToLive">
           <data type="positiveInteger"/>
         </attribute>
       </define>
     </div>
     <div>
       <a:documentation>
         A QName list
       </a:documentation>

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

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

       <define name="serviceResult">
         <optional>
           <element name="displayName">
             <data type="string"/>
             <attribute name="xml:lang">
               <data type="language"/>
             </attribute>
           </element>
         </optional>
         <optional>
           <element name="service">
             <data type="anyURI"/>
           </element>
            </choice>
         </optional>
         <optional>
            <a:documentation>
              3xx, 4xx, and 4xx responses.
            </a:documentation>
           <choice>
             <ref name="error" /> name="serviceBoundary"/>
             <element name="serviceBoundaryReference">
               <ref name="serviceBoundaryKey"/>
             </element>
           </choice>
         </optional>
         <zeroOrMore>
           <element name="uri">
             <data type="anyURI"/>
           </element>
         </zeroOrMore>
         <optional>
           <element name="serviceNumber">
             <data type="string">
               <param name="pattern">[0-9]+</param>
             </data>
           </element>
         </optional>
         <optional>
           <element name="valid">
             <ref name="redirect" name="qnameList" />
           </element>
         </optional>
         <optional>
           <element name="invalid">
             <ref name="failure" name="qnameList" />
            </choice>
           </element>
         </optional>
         <optional>
           <element name="unchecked">
             <ref name="extensionPoint" name="qnameList" />
           </element>
         </optional>
         <ref name="extensionPoint"/>
         <ref name="timeToLive"/>
         <ref name="message"/>
       </define>

     </div>

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

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

       <define name="query"> name="badRequest">
         <element name="locationInfo">
          <zeroOrMore> name="badRequest">
           <ref name="anyElement"/>
          </zeroOrMore> name="error"/>
         </element>
       </define>

       <define name="internalError">
         <element name="service">
          <data type="anyURI"/>
        </element> name="internalError">
           <ref name="extensionPoint" />
        <optional>
          <attribute name="operation">
            <a:defaultValue>recursive</a:defaultValue>
          </attribute>
        </optional> name="error"/>
         </element>
       </define>

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

     </div>

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

       <define name="result"> name="recursionError">
         <a:documentation>
          2xx response.
           Recursion error.
         </a:documentation>
        <element name="result">
         <optional>
            <element name="displayName">
              <data type="string"/>
           <attribute name="xml:lang"> name="failedReferral">
             <data type="language" /> type="anyURI"/>
           </attribute>
            </element>
         </optional>
          <element name="service">
            <data type="anyURI"/>
          </element>
         <optional>
            <element name="serviceBoundary">
           <choice>
                <group>
             <ref name="civicLocation" name="findService" />
                  <optional>
             <ref name="polygon" name="listServices" />
                  </optional>
                </group>
                <group>
                  <optional>
             <ref name="civicLocation" name="getServiceBoundary" />
           </choice>
         </optional>
         <ref name="polygon" />
                </group>
              </choice> name="error"/>
       </define>

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

       <define name="notFound">
         <element name="uri">
              <data type="anyURI"/> name="notFound">
           <ref name="recursionError"/>
         </element>
          </oneOrMore>
          <optional>
         <ref name="timeToLive"/>
       </define>

       <define name="serviceNotImplemented">
         <element name="serviceNumber">
              <data type="string">
                <param name="pattern">[0-9]+</param>
              </data> name="serviceNotImplemented">
           <ref name="recursionError"/>
         </element>
          </optional>
          <optional>
         <ref name="timeToLive"/>
       </define>

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

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

       <define name="locationProfileError">
         <element name="locationProfileError">
           <attribute name="unsupportedProfiles">
             <list>
               <zeroOrMore>
                 <data type="QName"/> type="anyURI"/>
               </zeroOrMore>
             </list>
            </element>
          </optional>
          <ref name="extensionPoint" />
          <attribute name="timeToLive">
            <data type="positiveInteger"/>
           </attribute>
           <ref name="status" /> name="recursionError"/>
         </element>
       </define>

     </div>

     <div>
       <a:documentation>
        Non-result responses.
      </a:documentation>

      <define name="error">
        <a:documentation>
          5xx response.
         Redirects.
       </a:documentation>
        <element name="error">
          <ref name="status"/>
          <ref name="extensionPoint" />
        </element>
      </define>

       <define name="redirect">
         <a:documentation>
          3xx response.
           Redirect pattern
         </a:documentation>
        <element name="redirect">
          <ref name="status"/>
         <attribute name="redirect">
           <data type="anyURI"/>
         </attribute>
         <ref name="extensionPoint" />
        </element> name="error"/>
       </define>

       <define name="failure">
        <a:documentation>
          4xx response.
        </a:documentation> name="movedPermenantly">
         <element name="failure"> name="movedPermanently">
           <ref name="status"/>
          <zeroOrMore> name="redirect"/>
         </element>
       </define>

       <define name="movedTemporarily">
         <element name="cause">
              <attribute name="name">
                <data type="QName"/>
              </attribute>
              <attribute name="message">
                <data type="string"/>
              </attribute>
              <attribute name="xml:lang">
                <data type="language"/>
              </attribute> name="movedTemporarily">
           <ref name="redirect"/>
         </element>
          </zeroOrMore>
         <ref name="extensionPoint" name="timeToLive" />
       </define>

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

     </div>

     <div>
       <a:documentation>
        Status
         Message pattern.
       </a:documentation>

       <define name="status">
        <attribute name="status">
          <data type="positiveInteger"/>
        </attribute>
        <optional>
          <attribute name="extendedStatus">
            <data type="positiveInteger"/>
          </attribute>
        </optional> name="message">
         <optional>
           <group>
             <attribute name="message">
               <data type="string"/>
             </attribute>
             <attribute name="xml:lang">
               <data type="language"/>
             </attribute>
           </group>
         </optional>
       </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>
        <element>
          <anyName/>
         <zeroOrMore>
           <choice>
             <element>
               <anyName/>
               <ref name="anyElement"/>
             </element>
             <attribute>
               <anyName/>
             </attribute>
             <text/>
              <ref name="anyElement"/>
           </choice>
         </zeroOrMore>
        </element>
       </define>

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

       <define name="civicAddress"> name="point2d">
         <a:documentation>
           A pattern to include the GEOPRIV civil location elements. 2D point from GML.
         </a:documentation>
        <element>
          <nsName ns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
          <zeroOrMore>
            <choice>
              <attribute>
                <anyName/>
         <element name="position" ns="http://www.opengis.net/gml">
           <element name="Point">
             <attribute name="srsName">
               <value>urn:ogc:def:crs:EPSG:4326</value>
             </attribute>
             <element name="pos">
               <text/>
              <ref name="anyElement"/>
            </choice>
          </zeroOrMore>
             </element>
           </element>
         </element>
       </define>

       <define name="civicLocation"> name="linearRing">
         <a:documentation>
           A definition of civic location Linear Ring from GEOPRIV. GML.
         </a:documentation>
         <element name="civicLocation">
          <zeroOrMore>
            <ref name="civicAddress"/>
          </zeroOrMore>
          <zeroOrMore>
            <ref name="anyElement" />
          </zeroOrMore> name="LinearRing" ns="http://www.opengis.net/gml">
           <element name="pos">
             <text/>
           </element>
         </element>
       </define>

       <define name="GML"> name="polygon">
         <a:documentation>
           A pattern to include GML elements. Polygon from GML.
         </a:documentation>
        <element>
          <nsName ns="http://www.opengis.net/gml" />
          <zeroOrMore>
            <choice>
              <attribute>
                <anyName/>
              </attribute>
              <text/>
              <ref name="anyElement" />
            </choice>
          </zeroOrMore>
        </element>
      </define>

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

   </grammar>

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

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