<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY RFC2119 SYSTEM
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
    <!ENTITY RFC2616 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
    <!ENTITY RFC2717 SYSTEM
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2717.xml">
    <!ENTITY RFC2818 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'>
    <!ENTITY RFC3023 SYSTEM
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3023.xml">
    <!ENTITY RFC3261 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
    <!ENTITY RFC3553 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3553.xml'>
    <!ENTITY RFC3833 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3833.xml'>
    <!ENTITY RFC3921 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3921.xml'>
    <!ENTITY RFC3958 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml'>
    <!ENTITY RFC3966 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml'>
    <!ENTITY rfc4119 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml'>
    <!ENTITY RFC4288 SYSTEM
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml">
    <!ENTITY RFC4033 SYSTEM
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
    <!ENTITY RFC4848 SYSTEM
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4848.xml">
    <!ENTITY RFC5222 SYSTEM
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml">
]>
<rfc updates="RFC 5222, RFC 5012" ipr="trust200902" category="std">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="no" ?>
  <?rfc sortrefs="yes"?>
  <?rfc rfcedstyle="yes" ?>
  <?rfc subcompact="no"?>

  <front>
    <title abbrev="LoST">LoST: A Location-to-Service Translation Protocol</title>
    <author initials="T." surname="Hardie" fullname="Ted Hardie">
      <organization/>
      <address>
        <email>ted.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="A." surname="Newton" fullname="Andrew Newton">
      <organization>American Registry for Internet Numbers</organization>
      <address>
        <postal>
          <street>3635 Concorde Parkway, Suite 200</street>
          <city>Chantilly</city>
          <region>VA</region>
          <code>20151</code>
          <country>US</country>
        </postal>
        <phone>+1 703 227 9894</phone>
        <email>andy@hxr.us</email>
      </address>
    </author>
    <author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
      <organization>Columbia University</organization>
      <address>
        <postal>
          <street>Department of Computer Science</street>
          <street>450 Computer Science Building</street>
          <city>New York</city>
          <region>NY</region>
          <code>10027</code>
          <country>US</country>
        </postal>
        <phone>+1 212 939 7004</phone>
        <email>hgs+ecrit@cs.columbia.edu</email>
        <uri>http://www.cs.columbia.edu</uri>
      </address>
    </author>
    <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@nsn.com</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    <date year="2009"/>
    <area>Real-time Applications and Infrastructure</area>
    <workgroup>ECRIT</workgroup>

    <abstract>

      <t>This document describes an XML-based protocol for mapping service identifiers and geodetic
        or civic location information to service contact URIs. In particular, it can be used to
        determine the location-appropriate Public Safety Answering Point (PSAP) for emergency
        services.</t>

      <t>This document is a revision of the original LoST specification, descrbed in RFC 5222.</t>
    </abstract>
  </front>
  <middle>

    <!-- **************************************************************************************** -->
    <section title="Introduction">

      <t>Protocols such as Naming Authority Pointer (NAPTR) records and the Service Location
        Protocol (SLP) can be used to discover servers offering a particular service. However, for
        an important class of services the appropriate specific service instance depends both on the
        identity of the service and the geographic location of the entity that needs to reach it.
        Emergency telecommunications services are an important example; here, the service instance
        is a Public Safety Answering Point (PSAP) that has jurisdiction over the location of the
        user making the call. The desired PSAP isn't necessarily the one that is topologically or
        even line-of-sight closest to the caller; rather, it is the one that serves the caller's
        location based on jurisdictional boundaries.</t>

      <t>This document describes a protocol for mapping a service identifier and location
        information compatible with the Presence Information Data Format Location Object <xref
          target="RFC4119">(PIDF-LO)</xref> to one or more service URIs. Service identifiers take
        the form of the service URNs described in <xref target="RFC5031"/>. Location information
        here includes revised civic location information <xref target="RFC5139"/> and a subset of
        the PIDF-LO profile <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>, which consequently
        includes the Geo-Shapes <xref target="geo-shapes"/> defined for GML <xref target="GML"/>.
        Example service URI schemes include sip <xref target="RFC3261"/>, xmpp <xref
          target="RFC3921"/>, and tel <xref target="RFC3966"/>. While the initial focus is on
        providing mapping functions for emergency services, it is likely that the protocol is
        applicable to other service URNs. For example, in the United States, the "2-1-1" and "3-1-1"
        service numbers follow a similar location-to-service behavior as emergency services.</t>

      <t>This document names this protocol "LoST", for Location-to-Service Translation. LoST
        satisfies the requirements <xref target="RFC5012"/> for mapping protocols. LoST provides a
        number of operations, centered around mapping locations and service URNs to service URLs and
        associated information. LoST mapping queries can contain either civic or geodetic location
        information. For civic addresses, LoST can indicate which parts of the civic address are
        known to be valid or invalid, thus providing address validation, as described in Section 3.5
        of <xref target="RFC5012"/>. LoST indicates errors in the location data to facilitate
        debugging and proper user feedback, but also provides best-effort answers.</t>

      <t>LoST queries can be resolved recursively or iteratively. To minimize round trips and to
        provide robustness against network failures, LoST supports caching of individual mappings
        and indicates the region for which the same answer would be returned ("service region").</t>

      <t>As defined in this document, LoST messages are carried in HTTP and HTTPS protocol
        exchanges, facilitating use of TLS for protecting the integrity and confidentiality of
        requests and responses.</t>

      <t>This document focuses on the description of the protocol between the mapping client and the
        mapping server. Other functions, such as discovery of mapping servers, data replication and
        the overall mapping server architecture are described in a separate document <xref
          target="I-D.ietf-ecrit-mapping-arch"/>.</t>

      <t>The query message carries location information and a service identifier encoded as a
        Uniform Resource Name (URN) (see <xref target="RFC5031"/>) from the LoST client to the LoST
        server. The LoST server uses its database to map the input values to one or more Uniform
        Resource Identifiers (URIs) and returns those URIs along with optional information, such as
        a service boundary, in a response message to the LoST client. If the server cannot resolve
        the query itself, it may in turn query another server or return the address of another LoST
        server, identified by a LoST server name. In addition to the mapping function described in
          <xref target="findService"/>, the protocol also allows to retrieve the service boundary
        (see <xref target="getServiceBoundary"/>) and to list the services available for a
        particular location (see <xref target="listServicesByLocation"/>) or supported by a
        particular server (see <xref target="listServices"/>).</t>

    </section>

    <!-- **************************************************************************************** -->
    <section title="Terminology and Requirements Notation">

      <t>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
          <xref target="RFC2119"/>.</t>

      <t>This document uses the following terms: <list style="hanging">

          <t hangText="Mapping:"><vspace blankLines="0"/> Mapping is a process that takes a location
            and a service identifier as inputs and returns one or more URIs. Those URIs can point
            either to a host providing that service or to a host that in turn routes the request to
            the final destination. This definition is a generalization of the term "mapping" as used
            in <xref target="RFC5012"/>, because LoST can be used for non-emergency services.</t>

          <t hangText="Mapping Data:"><vspace blankLines="0"/> Mapping data refers to a data
            structure that is defined in <xref target="mapping"/>. </t>

          <t hangText="Service boundary:"><vspace blankLines="0"/> A service boundary circumscribes
            the region within which all locations map to the same service URI or set of URIs for a
            given service. A service boundary may consist of several non-contiguous geometric
            shapes. Note that service boundary is an artifical construct when used in LoST as the
            described region may not necessarily need to reflect the real world boundary. This
            simplification is made to allow a person operating a LoST server to balance the tradeoff
            between the size of a precise service boundary description and the protocol performance
            gained by returning any form of service boundary.</t>

          <t hangText="LoST client:"><vspace blankLines="0"/> A host acts as a LoST client if it
            sends LoST query messages and receives LoST response messages.</t>

          <t hangText="LoST server:"><vspace blankLines="0"/> A host acts as a LoST server if it
            receives LoST query messages and sends LoST response messages. In recursive operation,
            the same entity may be both a client and a server.</t>

          <t hangText="Authoritative LoST server:"><vspace blankLines="0"/> An authoritative server
            acts only as a server and successfully resolves the input location and service
            identifier to a URI or set of URIs.</t>

          <t hangText="Validation:"><vspace blankLines="0"/> The term "validation" can be separated
            into two categories, namely <list style="hanging">
              <t hangText="Routing Valid:"><vspace blankLines="0"/> Location information is
                considered valid if the civic or geographic location can be mapped to one or more
                PSAPs. </t>
              <t hangText="Dispatch Valid:"><vspace blankLines="0"/> Location information is
                considered dispatch valid if a provided civic address exists in a given reference
                database. Note that the criteria for matching a given address with the reference
                database may not require the comparison of every civic address token in the provided
                address. </t>
            </list>
          </t>

        </list>
      </t>

      <t>Additional emergency service terminology can be found in <xref target="RFC5012"/>.</t>

    </section>

    <!-- **************************************************************************************** -->

    <section anchor="usage" title="Overview of Protocol Usage">

      <t>The LoST protocol supports the following types of queries and responses:</t>

      <t>
        <list style="hanging">

          <t hangText="&lt;findService&gt; and
&lt;findServiceResponse&gt;">
            <vspace blankLines="0"/> A LoST client retrieves contact URIs based on location
            information and a service identifier with this request and response. The same query type
            may also ask for location validation. The details can be found in <xref
              target="findService"/>.</t>

          <t
            hangText="&lt;getServiceBoundary&gt; and
&lt;getServiceBoundaryResponse&gt;">
            <vspace blankLines="0"/> A LoST client obtains a service boundary with this request and
            response, as described in <xref target="getServiceBoundary"/>. </t>

          <t hangText="&lt;listServices&gt; and
&lt;listServicesResponse&gt;">
            <vspace blankLines="0"/> With this request and response, a LoST client can find out
            which services a LoST server supports, as described in <xref target="listServices"/>. </t>

          <t
            hangText="&lt;listServicesByLocation&gt; and
&lt;listServicesByLocationResponse&gt;">
            <vspace blankLines="0"/> A LoST client can determine with this request and response
            which services are available for a specific location region. <xref
              target="listServicesByLocation"/> describes the details.</t>

        </list>
      </t>

      <t>LoST clients may initiate any of the above queries at any time. Among the common triggers
        are: <list style="numbers">
          <t>when the client initially starts up or attaches to a network;</t>

          <t>when the client detects that its location has changed sufficiently that it is outside
            the bounds of the service region;</t>

          <t>when a SIP message arrives at a SIP proxy performing location-based call routing;</t>

          <t>when cached mapping information has expired; and</t>

          <t>when invoking a particular service. At that time, a client may omit requests for
            service boundaries or other auxiliary information.</t>

        </list>
      </t>

      <t>A service-specific Best Current Practice (BCP) document, such as <xref
          target="I-D.ietf-ecrit-phonebcp"/>, governs whether a client is expected to invoke the
        mapping service just before needing the service or whether to rely on cached answers. Cache
        entries expire at their expiration time (see <xref target="expires"/>), or they become
        invalid if the caller's device moves beyond the boundaries of the service region.
        Service-specific Best Current Practice documents may also provide guidance on the contact
        URI schemes most appropriate to the service. As a general set of guidelines, URI schemes
        that do not provide mechanisms for actually initiating a contact method should be avoided
        (examples include data, info, cid, and tag) as transforming those references into contact
        mechanisms requires a layer of indirection that makes the overall mechanism more fragile.
        Provisionally registered URI schemes should also be carefully considered before use, because
        they are subject to change in core semantics.</t>

    </section>

    <!-- **************************************************************************************** -->
    <section anchor="lost" title="LoST Servers and Their Resolution">

      <t>LoST servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery
        Service) <xref target="RFC4848"/> application unique strings, in the form of a DNS name. An
        example is 'lostserver.example.com'.</t>

      <t>Clients need to use the U-NAPTR <xref target="RFC4848"/> specification described below to
        obtain a URI (indicating host and protocol) for the applicable LoST service. In this
        document, only the HTTP and HTTPS URL schemes are defined. Note that the HTTP URL can be any
        valid HTTP URL, including those containing path elements.</t>

      <t>The following two DNS entries show the U-NAPTR resolution for "example.com" to the HTTPS
        URL https://lostserv.example.com/secure or the HTTP URL http://lostserver.example.com, with
        the former being preferred.</t>

      <t>
        <figure>
          <artwork><![CDATA[
    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!"  ""
]]></artwork>
        </figure>
      </t>

      <t>Clients learn the LoST server's host name by means beyond the scope of this specification,
        such as SIP configuration and DHCP <xref target="RFC5223"/>.</t>

    </section>

    <!-- **************************************************************************************** -->

    <section anchor="mapping" title="The &lt;mapping> Element">

      <t>The &lt;mapping> element is the core data element in LoST, describing a service region
        and the associated service URLs. Its attributes and elements are described in subsections
        below. </t>

      <section anchor="source"
        title="The Mapping Data Source: 'source',
'sourceId', and 'lastUpdated' Attributes">

        <t>The 'source', 'sourceId', and 'lastUpdated' attributes uniquely identify a particular
          mapping record. They are created by the authoritative source for a mapping and are never
          modified when a mapping is served from a cache. All three attributes are REQUIRED for all
          &lt;mapping> elements. A receiver can replace a mapping in it's cache with another one
          having the same 'source' and 'sourceId' and a more recent time in 'lastUpdated'.</t>

        <t>The 'source' attribute contains a LoST application unique string identifying the
          authoritative generator of the mapping (see <xref target="lost"/>).</t>

        <t>The 'sourceId' attribute identifies a particular mapping and contains an opaque token
          that MUST be unique among all different mappings maintained by the authoritative source
          for that particular service. For example, a Universally Unique Identifier (UUID) is a
          suitable format.</t>

        <t>The 'lastUpdated' attribute describes when a specific instance of mapping, identified by
          the combination of 'source' and 'sourceId', was last changed. When any of the elements of
          the &lt;mapping> element is modified, for example by changing the &lt;uri> element
          or the service boundary, then this mapping has to be treated as a new instance and the
          value in the 'lastUpdated' attribute has to be re-computed. Another way to judge the need
          for a re-created mapping is when a digital signature covering that mapping would break
          because of a modification. The contents of the 'lastUpdated' attribute has the XML data
          type dateTime in its timezoned form, using the canonical UTC representation with the
          letter 'Z' as the timezone indicator.</t>

      </section>

      <section anchor="expires" title="Mapping Validity:  The 'expires'
Attribute">

        <t>The 'expires' attribute contains the absolute time at which the mapping becomes invalid.
          The contents of this attribute is a timezoned XML type dateTime, in canonical
          representation. The &lt;mapping> element MUST include the 'expires' attribute.</t>

        <t>Optionally, this attribute may contain the values of 'NO-CACHE' and 'NO-EXPIRATION'
          instead of a dateTime value. The value 'NO-CACHE' is an indication that the mapping should
          not be cached. The value of 'NO-EXPIRATION' is an indication that the mapping does not
          expire. Please note that the value of 'NO-EXPIRATION' has to be used with care and will
          typically only be used in a controlled environment where additional mechanisms can be used
          to update mappings that were initially thought to never change.</t>

        <t>On occasion, a server may be forced to return an expired mapping if it cannot reach the
          authoritative server or the server fails to return a usable answer. Clients and servers
          MAY cache the mapping so that they have at least some information available. Caching
          servers that have such stale information SHOULD re-attempt the query each time a client
          requests a mapping. Since the expired mapping will be returned to the client as a
          non-error/non-warning response, the client MUST check the 'expires' attribute; if the
          mapping has expired, local policy at the client determines whether it discards the answer
          and tries again later or uses the possibly stale response. </t>

      </section>

      <section anchor="displayName-element"
        title="Describing the Service with
the &lt;displayName> Element">

        <t>Zero or more &lt;displayName&gt; elements describe the service with a string that
          is suitable for display to human users, each annotated with the 'xml:lang' attribute that
          contains a language tag to aid in the rendering of text.</t>

      </section>

      <section anchor="service-response" title="The Mapped Service: The
&lt;service> Element">

        <t>The mandatory &lt;service&gt; element identifies the service for which this
          mapping applies. Two cases need to be distinguished when the LoST server sets the
          &lt;service&gt; element in the response message: <list style="numbers">

            <t>If the requested service, identified by the <xref target="RFC5031">service URN</xref>
              in the &lt;service> element of the request, exists for the location indicated,
              then the LoST server copies the service URN from the request into the
              &lt;service&gt; element.</t>

            <t>If, however, the requested service, identified by the <xref target="RFC5031">service
                URN</xref> in the &lt;service> element in the request, does not exist for the
              location indicated, the server either can return a <xref target="errors"
                >&lt;serviceNotImplemented&gt;</xref> error or can provide an alternate
              service that approximates the desired service for that location. In the latter case,
              the server MUST include a &lt;service&gt; element with the alternative service
              URN. The choice of service URN is left to local policy, but the alternate service
              should be able to satisfy the original service request.</t>

          </list></t>

      </section>

      <section anchor="serviceBoundary"
        title="Defining the Service Region
with the &lt;serviceBoundary> Element">

        <t> A response MAY indicate the region for which the service URL returned would be the same
          as in the actual query, the so-called service region. The service region can be indicated
          by value or by reference (see <xref target="serviceBoundaryReference"/>). If a client
          moves outside the service area and wishes to obtain current service data, it sends a new
          query with its current location. The service region is described by value in one or more
          &lt;serviceBoundary&gt; elements, each formatted according to a specific location
          profile, identified by the 'profile' attribute (see <xref target="location-profiles"/>).
          &lt;serviceBoundary&gt; elements formatted according to different location
          profiles are alternative representations of the same area, not additive to one another;
          this allows a client understanding only one of the profile types to be sure it has a
          complete view of the serviceBoundary. Within a serviceBoundary element there may, however,
          be multiple locations which are additive; this is necessary because some
          &lt;serviceBoundary&gt; areas could not be easily expressed with a single shape or
          civic location. <!-- Hannes (18. October 2009): --> If included in a response, the
          &lt;serviceBoundary&gt; element MUST contain at least one service boundary that
          uses the same profile as the request. </t>
        <t>A service boundary is requested by the client, using the 'serviceBoundary' attribute in
          the request with the value set to "value".</t>
      </section>

      <section anchor="serviceBoundaryReference"
        title="Service Boundaries by
Reference: The &lt;serviceBoundaryReference> Element">

        <t>Since geodetic service boundaries may contain thousands of points and can thus be quite
          large, clients may wish to conserve bandwidth by requesting a reference to the service
          boundary instead of the value described in <xref target="serviceBoundary"/>. The
          identifier of the service boundary is returned as an attribute of the
          &lt;serviceBoundaryReference> element, along with a LoST application unique string
          (see <xref target="lost"/>) identifying the server from where it can be retrieved. The
          actual value of the service boundary is then retrieved with the <xref
            target="getServiceBoundary">getServiceBoundary</xref> request.</t>

        <t>A reference to a service boundary is requested by the client using the 'serviceBoundary'
          attribute in the request with the value set to "reference". A LoST server may decide,
          based on local policy, to return the service boundary by value or to omit the
          &lt;serviceBoundaryReference> element in the response.</t>

        <t>The identifier is a random token with at least 128 bits of entropy and can be assumed to
          be globally unique. It uniquely references a particular boundary. If the boundary changes,
          a new identifier MUST be chosen. Because of these properties, a client receiving a mapping
          response can simply check if it already has a copy of the boundary with that identifier.
          If so, it can skip checking with the server whether the boundary has been updated. Since
          service boundaries are likely to remain unchanged for extended periods of time, possibly
          exceeding the normal lifetime of the service URL, this approach avoids unnecessarily
          refreshing the boundary information just because the remainder of the mapping has become
          invalid.</t>

      </section>

      <section anchor="serviceNumber"
        title="The Service Number: The
&lt;serviceNumber> Element ">

        <t>The service number is returned in the optional &lt;serviceNumber> element. It
          contains a string of digits, * and # that a user on a device with a 12-key dial pad could
          use to reach that particular service.</t>

      </section>

      <section anchor="uri-element" title="Service URLs: The &lt;uri> Element">

        <t>The response returns the service URLs in one or more &lt;uri&gt; elements. The
          URLs MUST be absolute URLs. The ordering of the URLs has no particular significance. Each
          URL scheme MUST only appear at most once, but it is permissible to include both secured
          and regular versions of a protocol, such as both 'http' and 'https' or 'sip' and 'sips'.</t>

      </section>
    </section>
    <!-- end mapping -->

    <!-- **************************************************************************************** -->

    <section anchor="path" title="Path of a Request: The &lt;path> Element">

      <t>To prevent loops and to allow tracing of request and response paths, all requests that
        allow recursion include a &lt;path> element that contains one or more &lt;via>
        elements, each possessing an attribute containing a LoST application unique string (see
          <xref target="lost"/>). The order of &lt;via> elements corresponds to the order of
        LoST servers, i.e., the first &lt;via> element identifies the server that initially
        received the request from the client issuing the request. Every server in a recursive query
        operation is included in the &lt;path> element, including the first server to receive
        it. </t>

      <t>The server that answers the request instead of forwarding it, such as the authoritative
        server, copies the &lt;path> element verbatim into the response. The &lt;path>
        element is not modified in responses as the responses traverses the server chain back to the
        querying client.</t>

      <t>If a query is answered iteratively, the querier includes all servers that it has already
        contacted.</t>

      <t>When a cached mapping is returned, then the &lt;path> element cached together with the
        mapping is returned.</t>

      <t>The example in <xref target="findServiceResponse-civic.xml"/> indicates that the answer was
        given to the client by the LoST server at esgw.ueber-110.de.example, which got the answer
        from the (authoritative) LoST server at polizei.muenchen.de.example.</t>

    </section>

    <!-- **************************************************************************************** -->

    <section anchor="locationUsed"
      title="Identifying the Location Element
Used for Mapping: &lt;locationUsed>">

      <t>Several of the requests can provide one or more &lt;location> elements, among which the
        server gets to choose. It is useful for the client to be able to determine which one was
        actually used in producing the result. For that purpose, the &lt;location> tag MUST
        contain an 'id' attribute that uniquely identifies the &lt;location> element. The format
        of the identifier is left to the client; it could, for example, use a hash of the location
        information. The server returns the identifier for the &lt;location> element it used in
        the &lt;locationUsed> tag.</t>

    </section>

    <!-- **************************************************************************************** -->

    <section anchor="findService"
      title="Mapping a
Location and Service to URLs: &lt;findService>">

      <section title="Overview">

        <t>The &lt;findService> query constitutes the core of the LoST functionality, mapping
          civic or geodetic locations to URLs and associated data. After giving an example, we
          enumerate the elements of the query and response.</t>

      </section>

      <section title="Examples">

        <section anchor="findService-geo-example" title="Example Using Geodetic
Coordinates">

          <t>The following is an example of mapping a service to a location using geodetic
            coordinates, for the service associated with the police (<spanx style="code"
              >urn:service:sos.police</spanx>).</t>

          <figure anchor="findService-geo.xml" title="A &lt;findService&gt; geodetic query">
            <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findService 
  xmlns="urn:ietf:params:xml:ns:lost1" 
  xmlns:p2="http://www.opengis.net/gml" 
  serviceBoundary="value" 
  recursive="true">
  
  <location id="6020688f1ce1896d" profile="geodetic-2d">
    <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
       <p2:pos>37.775 -122.422</p2:pos>
    </p2:Point>
  </location>
  <service>urn:service:sos.police</service>

</findService>
]]></artwork>
          </figure>

          <t>Given the query above, a server would respond with a service, and information related
            to that service. In the example below, the server has mapped the location given by the
            client for a police service to the New York City Police Department, instructing the
            client that it may contact them via the URIs <spanx style="verb"
            >sip:nypd@example.com</spanx> and <spanx style="verb">xmpp:nypd@example.com</spanx>. The
            server has also given the client a geodetic, two-dimensional boundary for this service.
            The mapping was last updated on November 1, 2006 and expires on January 1, 2007. If the
            client's location changes beyond the given service boundary or the expiration time has
            been reached, it may want to requery for this information, depending on the usage
            environment of LoST.</t>

          <figure anchor="findServiceResponse-geo.xml"
            title="A &lt;findServiceResponse&gt; geodetic answer">
            <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
  xmlns:p2="http://www.opengis.net/gml">
  <mapping 
    expires="2007-01-01T01:44:33Z"
    lastUpdated="2006-11-01T01:00:00Z"
    source="authoritative.example"
    sourceId="7e3f40b098c711dbb6060800200c9a66">
    <displayName xml:lang="en">
      New York City Police Department
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary profile="geodetic-2d">
      <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
        <p2:exterior>
          <p2:LinearRing>
            <p2:pos>37.775 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4194</p2:pos>
          </p2:LinearRing>
        </p2:exterior>
      </p2:Polygon>
    </serviceBoundary>
    <uri>sip:nypd@example.com</uri>
    <uri>xmpp:nypd@example.com</uri>
    <serviceNumber>911</serviceNumber>
  </mapping>
  <path>
    <via source="resolver.example"/>
    <via source="authoritative.example"/>
  </path>
  <locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
]]></artwork>
          </figure>
        </section>

        <section anchor="findService-civic-example" title="Civic Address Mapping
Example">

          <t>The example below shows how to map a service to a location much like the example in
              <xref target="findService-geo-example"/>, but using civic address location
            information. In this example, the client requests the service associated with police
            (urn:service:sos.police) along with a specific civic address (house number 6 on a street
            named Otto-Hahn-Ring in Munich, Germany).</t>

          <figure anchor="findService-civic.xml"
            title="A &lt;findService&gt; civic address query">
            <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1"
  recursive="true" serviceBoundary="value">
  <location id="627b8bf819d0bad4d" profile="civic">
    <civicAddress 
      xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
      <country>DE</country>
      <A1>Bavaria</A1>
      <A3>Munich</A3>
      <A6>Otto-Hahn-Ring</A6>
      <HNO>6</HNO>
      <PC>81675</PC>
    </civicAddress>
  </location>
  <service>urn:service:sos.police</service>
</findService>
]]></artwork>
          </figure>

          <t>Given the query above, a server would respond with a service, and information related
            to that service. In the example below, the server has mapped the location given by the
            client for a police service to the Muenchen Polizei-Abteilung, instructing the client
            that it may contact them via the URIs sip:munich-police@example.com and
            xmpp:munich-police@example.com. The server has also given the client a civic address
            boundary (the city of Munich) for this service. The mapping was last updated on November
            1, 2006 by the authoritative source <spanx style="verb"
            >polizei.muenchen.de.example</spanx> and expires on January 1, 2007. This instructs the
            client to requery for the information if its location changes beyond the given service
            boundary (i.e., beyond the indicated district of Munich) or after January 1, 2007.</t>

          <figure anchor="findServiceResponse-civic.xml"
            title="A &lt;findServiceResponse&gt; civic address answer">
            <artwork xml:space="preserve">
<![CDATA[
 <?xml version="1.0" encoding="UTF-8"?>
 <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
   <mapping
     expires="2007-01-01T01:44:33Z"
     lastUpdated="2006-11-01T01:00:00Z"
     source="esgw.ueber-110.de.example"
     sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
     <displayName xml:lang="de">
       Muenchen Polizei-Abteilung
     </displayName>
     <service>urn:service:sos.police</service>
     <serviceBoundary
       profile="civic">
       <civicAddress
         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         <country>DE</country>
         <A1>Bavaria</A1>
         <A3>Munich</A3>
         <PC>81675</PC>
       </civicAddress>
     </serviceBoundary>
     <uri>sip:munich-police@example.com</uri>
     <uri>xmpp:munich-police@example.com</uri>
     <serviceNumber>110</serviceNumber>
   </mapping>
   <path>
     <via source="esgw.ueber-110.de.example"/>
     <via source="polizei.muenchen.de.example"/>
   </path>
   <locationUsed id="627b8bf819d0bad4d"/>
 </findServiceResponse>
]]></artwork>
          </figure>

        </section>
      </section>

      <section anchor="findServiceQuery"
        title="Components of
the &lt;findService&gt; Request">

        <t>The &lt;findService> request includes attributes and elements that govern whether the
          request is handled iteratively or recursively, whether location validation is performed,
          and which elements may be contained in the response.</t>

        <section anchor="location-element" title="The &lt;location> Element">

          <t>The &lt;findService&gt; query communicates location information using one or
            more &lt;location&gt; elements, which MUST conform to a location profile (see
              <xref target="location-profiles"/>). There MUST NOT be more than one location element
            for each distinct location profile. The order of location elements is significant; the
            server uses the first location element where it understands the location profile.</t>

        </section>

        <section anchor="service-element"
          title="Identifying the Service:  The
&lt;service> Element">

          <t>The type of service desired is specified by the &lt;service&gt; element. It
            contains service URNs from the registry established in <xref target="RFC5031"/>.</t>

        </section>

        <section anchor="recursive" title="Recursion and Iteration">

          <t>LoST can operate in either recursive or iterative mode, on a request-by-request basis.
            In recursive mode, the LoST server initiates queries on behalf of the requester and
            returns the result to the requester.</t>

          <t>In iterative mode, the server contacted returns a redirection response indicating the
            next server to be queried if the server contacted cannot provide an answer itself.</t>

          <t>For the queries defined in this document, only the LoST &lt;findService> and
            &lt;listServicesByLocation> queries can be recursive, as indicated by the
            'recursive' attribute. A value of "true" indicates a recursive query, with the default
            being "false" when the attribute is omitted. Regardless of the attribute, a server MAY
            always answer a query by providing a LoST application unique string (see <xref
              target="lost"/>), i.e., indirection; however, it MUST NOT recurse if the attribute is
            "false".</t>

        </section>

        <section anchor="boundary" title="Service Boundary">

          <t>LoST &lt;mapping> elements can describe the service boundary either by value or by
            reference. Returning a service boundary reference is generally more space-efficient for
            geospatial (polygon) boundaries and if the boundaries change rarely, but does incur an
            additional &lt;getServiceBoundary> request. The querier can express a preference for
            one or the other modality with the 'serviceBoundary' attribute in the
            &lt;findService> request, but the server makes the final decision as to whether to
            return a reference or a value.
            <!-- Servers SHOULD NOT return
a by-value service boundaries if the querier requested a reference.-->
          </t>

        </section>

        <section anchor="validateLocation" title="Requesting Civic Location Validation">

          <t>Civic address validation is requested by setting the optional attribute
            'validateLocation' to true. If the attribute is omitted, it is assumed to be false. The
            response is described in <xref target="validation"/>. The example in <xref
              target="findService-civic-validation.xml"/> demonstrates address validation. If the
            server chooses a geodetic location among the locations provided in a request, the
            attribute is ignored.</t>

          <t>
            <figure anchor="findService-civic-validation.xml"
              title="A &lt;findService> query with address validation request">
              <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findService 
  xmlns="urn:ietf:params:xml:ns:lost1"
  recursive="true" 
  validateLocation="true" 
  serviceBoundary="value">
  <location id="627b8bf819d0bad4d" profile="civic">
    <civicAddress 
      xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
      <country>DE</country>
      <A1>Bavaria</A1>
      <A3>Munich</A3>
      <A6>Otto-Hahn-Ring</A6>
      <HNO>6</HNO>
      <PC>81675</PC>
    </civicAddress>
  </location>
  <service>urn:service:sos.police</service>
</findService>
]]></artwork>
            </figure>
          </t>

          <t>
            <figure anchor="findServiceResponse-civic-validation.xml"
              title="A &lt;findServiceResponse> message with address validation information">
              <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
  <mapping 
    expires="2007-01-01T01:44:33Z"
    lastUpdated="2006-11-01T01:00:00Z"
    source="authoritative.example"
    sourceId="4db898df52b84edfa9b6445ea8a0328e">
    <displayName xml:lang="de">
      Muenchen Polizei-Abteilung
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary profile="civic">
      <civicAddress 
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
        <country>DE</country>
        <A1>Bavaria</A1>
        <A3>Munich</A3>
        <PC>81675</PC>
      </civicAddress>
    </serviceBoundary>
    <uri>sip:munich-police@example.com</uri>
    <uri>xmpp:munich-police@example.com</uri>
    <serviceNumber>110</serviceNumber>
  </mapping>
  <locationValidation>
    <valid>country A1 A3 A6</valid>
    <invalid>PC</invalid>
    <unchecked>HNO</unchecked>
  </locationValidation>
  <path>
    <via source="resolver.example"/>
    <via source="authoritative.example"/>
  </path>
  <locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse>
]]></artwork>
            </figure>
          </t>
        </section>
      </section>

      <!-- **************************************************************************************** -->

      <section anchor="findServiceResponse"
        title="Components of the Mapping
Response &lt;findServiceResponse&gt;">

        <section title="Overview">

          <t>Mapping responses consist of the &lt;mapping> element (<xref target="mapping"/>)
            describing the mapping itself, possibly followed by <xref target="warnings"
            >warnings</xref>, <xref target="validation">location validation information</xref>, and
            an indication of the <xref target="path">path</xref> the response has taken.</t>

        </section>

        <section anchor="validation"
          title="Civic Address Validation: The
&lt;locationValidation> Element">

          <t>A server can indicate in its response which civic address elements it has recognized as
            valid, which ones it has ignored, and which ones it has checked and found to be invalid.
            The server SHOULD include this information if the 'validateLocation' attribute in the
            request was true, but local policy at the server may allow this information to be
            omitted. Each element contains a list of tokens separated by whitespace, enumerating the
            civic location labels used in child elements of the &lt;civicAddress> element. The
            &lt;valid> element enumerates those civic address elements that have been recognized
            as valid by the LoST server and that have been used to determine the mapping. The
            &lt;unchecked> elements enumerates the civic address elements that the server did
            not check and that were not used in determining the response. The &lt;invalid>
            element enumerate civic address elements that the server attempted to check, but that
            did not match the other civic address elements found in the &lt;valid> list. Civic
            location tokens that are not listed in either the &lt;valid>, &lt;invalid>, or
            &lt;unchecked> element belong to the class of unchecked tokens.</t>

          <t>Note that the same address can yield different responses if parts of the civic address
            contradict each other. For example, if the postal code does not match the city, local
            server policy determines whether the postal code or the city is considered valid. The
            mapping naturally corresponds to the valid elements.</t>

          <t>The example shown in <xref target="findService-civic-validation.xml"/> and in <xref
              target="findServiceResponse-civic-validation.xml"/> indicates that the tokens
            'country', 'A1', 'A3', and 'A6' have been validated by the LoST server. The server
            considered the postal code 81675 in the &lt;PC> element as not valid for this
            location. The 'HNO' token belongs to the class of unchecked location tokens.</t>
        </section>

      </section>
    </section>
    <!-- end findService -->

    <!-- **************************************************************************************** -->
    <section anchor="getServiceBoundary"
      title="Retrieving the Service
Boundary via &lt;getServiceBoundary>">

      <t>As discussed in <xref target="serviceBoundary"/>,
        <!--[mf] Kate asks if this should be Section 5.5 instead of 5.6.  AQ? --> the
        &lt;findServiceResponse&gt; can return a globally unique identifier in the
        'serviceBoundary' attribute that can be used to retrieve the service boundary, rather than
        returning the boundary by value. This is shown in the example in <xref
          target="findService-geo-serviceBoundaryReference"/> and <xref
          target="findServiceResponse-geo-reference"/>. The client can then retrieve the boundary
        using the &lt;getServiceBoundary> request and obtains the boundary in the
        &lt;getServiceBoundaryResponse>, illustrated in the example in <xref
          target="getServiceBoundary.xml"/> and <xref target="getServiceBoundaryResponse-civic.xml"
        />. The client issues the request to the server identified in the 'server' attribute of the
        &lt;serviceBoundaryReference> element. These requests are always directed to the
        authoritative server and do not recurse.</t>

      <t>
        <figure anchor="findService-geo-serviceBoundaryReference"
          title="&lt;findService> request and response with service boundary reference">
          <artwork>
            <![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findService 
  xmlns="urn:ietf:params:xml:ns:lost1"
  xmlns:p2="http://www.opengis.net/gml" 
  recursive="true"
  serviceBoundary="reference">
  <location id="6020688f1ce1896d" profile="geodetic-2d">
    <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
       <p2:pos>37.775 -122.422</p2:pos>
    </p2:Point>
  </location>
  <service>urn:service:sos.police</service>
</findService>
]]></artwork>
        </figure>
      </t>
      <t>
        <figure anchor="findServiceResponse-geo-reference"
          title="&lt;findServiceResponse> message with service boundary reference">
          <artwork>
            <![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" 
  xmlns:p2="http://www.opengis.net/gml">
  <mapping 
    expires="2007-01-01T01:44:33Z"
    lastUpdated="2006-11-01T01:00:00Z"
    source="authoritative.example"
    sourceId="7e3f40b098c711dbb6060800200c9a66">
    <displayName xml:lang="en">
      New York City Police Department
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundaryReference 
      source="authoritative.example"
      key="7214148E0433AFE2FA2D48003D31172E"/>
    <uri>sip:nypd@example.com</uri>
    <uri>xmpp:nypd@example.com</uri>
    <serviceNumber>911</serviceNumber>
  </mapping>
  <path>
    <via source="resolver.example"/>
    <via source="authoritative.example"/>
  </path>
  <locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
]]></artwork>
        </figure>
      </t>
      <t>
        <figure anchor="getServiceBoundary.xml"
          title="Requesting a service boundary with &lt;getServiceBoundary>">
          <artwork>
            <![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1" 
    key="7214148E0433AFE2FA2D48003D31172E"/>
]]></artwork>
        </figure>
      </t>

      <figure anchor="getServiceBoundaryResponse-civic.xml"
        title="Geodetic service boundary response">
        <artwork>
          <![CDATA[
 <?xml version="1.0" encoding="UTF-8"?>
 <getServiceBoundaryResponse
   xmlns="urn:ietf:params:xml:ns:lost1">
     <serviceBoundary profile="geodetic-2d">
       <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
         <p2:exterior>
           <p2:LinearRing>
             <p2:pos>37.775 -122.4194</p2:pos>
             <p2:pos>37.555 -122.4194</p2:pos>
             <p2:pos>37.555 -122.4264</p2:pos>
             <p2:pos>37.775 -122.4264</p2:pos>
             <p2:pos>37.775 -122.4194</p2:pos>
           </p2:LinearRing>
         </p2:exterior>
       </p2:Polygon>
     </serviceBoundary>
   <path>
     <via source="resolver.example"/>
     <via source="authoritative.example"/>
   </path>
 </getServiceBoundaryResponse>
]]></artwork>
      </figure>

    </section>

    <!-- **************************************************************************************** -->
    <section anchor="listServices" title="List Services: &lt;listServices>">

      <t>A LoST client can ask a LoST server for the list of services that it understands, primarily
        for diagnostic purposes. The query does not contain location information, as it simply
        provides an indication of which services the server can look up, not whether a particular
        service is offered for a particular area. Typically, only top-level services are included in
        the answer, implying support for all sub-services. Since the query is answered by the
        queried server, there is no notion of recursion or indirection. The <xref
          target="listServicesByLocation">&lt;listServicesByLocation></xref> query below can be
        used to find out whether a particular service is offered for a specific location. An example
        request and response are shown in <xref target="listServices.xml"/>.</t>

      <t>
        <figure anchor="listServices.xml" title="Example of &lt;ListServices> query">
          <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<listServices 
  xmlns="urn:ietf:params:xml:ns:lost1">
  <service>urn:service:sos</service>
</listServices>
]]></artwork>
        </figure>
      </t>
      <t>
        <figure anchor="listServicesResponse.xml" title="Example of &lt;ListServicesResponse>">
          <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<listServicesResponse 
 xmlns="urn:ietf:params:xml:ns:lost1">
 <serviceList>
  urn:service:sos.ambulance
  urn:service:sos.animal-control
  urn:service:sos.fire
  urn:service:sos.gas
  urn:service:sos.mountain
  urn:service:sos.marine
  urn:service:sos.physician
  urn:service:sos.poison
  urn:service:sos.police
 </serviceList>
 <path>
  <via source="authoritative.example"/>
 </path>
</listServicesResponse>
]]></artwork>
        </figure>
      </t>
    </section>

    <!-- **************************************************************************************** -->
    <section anchor="listServicesByLocation"
      title="List Services By Location: &lt;listServicesByLocation>">

      <t>A LoST client can ask a LoST server for the list of services it knows about for a
        particular area. The &lt;listServicesByLocation> query contains one or more
        &lt;location&gt; elements, each from a different <xref target="location-profiles"
          >location profile</xref>, and may contain the &lt;service&gt; element. As for
        &lt;findService>, the server selects the first location element that has a profile the
        server understands and it can operate either recursively or iteratively; &lt;via>
        elements track the progress of the request. The query indicates the services that the server
        can enumerate from within the forest structure of which it is a part. Because LoST does not
        presume a single, overarching organization of all potential service types, there may be
        services available within a geographic area that could be described by other LoST servers
        connected to other forest structures. As an example, the emergency services forest for a
        region may be distinct from the forests that locate commercial services within the same
        region.</t>

      <t>If the query contains the &lt;service&gt; element, the LoST server returns only
        immediate child services of the queried service that are available for the provided
        location. If the &lt;service&gt; element is absent, the LoST service returns all
        top-level services available for the provided location that it knows about.</t>

      <t>A server responds to this query with a &lt;listServicesByLocationResponse&gt;
        response. This response contains &lt;via&gt; elements (see <xref target="path"/>)
        and MUST contain a &lt;serviceList&gt; element, consisting of a whitespace-separated
        list of service URNs. The query and response are illustrated in <xref
          target="listServicesByLocation-geo.xml"/> and in <xref
          target="listServicesByLocationResponse.xml"/>, respectively.</t>

      <t>
        <figure anchor="listServicesByLocation-geo.xml"
          title="Example of &lt;ListServicesbyLocation> query">
          <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation
  xmlns="urn:ietf:params:xml:ns:lost1" 
  xmlns:p2="http://www.opengis.net/gml"
  recursive="true">
  <location id="3e19dfb3b9828c3" profile="geodetic-2d">
    <p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
      <p2:pos>-34.407 150.883</p2:pos>
    </p2:Point> 
  </location>
  <service>urn:service:sos</service>
</listServicesByLocation>
]]></artwork>
        </figure>
      </t>

      <t>
        <figure anchor="listServicesByLocationResponse.xml"
          title="Example of &lt;ListServicesByLocationResponse> response">
          <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse 
 xmlns="urn:ietf:params:xml:ns:lost1">
 <serviceList>
  urn:service:sos.ambulance
  urn:service:sos.animal-control
  urn:service:sos.fire
  urn:service:sos.gas
  urn:service:sos.mountain
  urn:service:sos.marine
  urn:service:sos.physician
  urn:service:sos.poison
  urn:service:sos.police
 </serviceList>
 <path>
  <via source="resolver.example"/>
  <via source="authoritative.example"/>
 </path>
 <locationUsed id="3e19dfb3b9828c3"/>
</listServicesByLocationResponse>
]]></artwork>
        </figure>
      </t>
    </section>

    <!-- **************************************************************************************** -->
    <section anchor="location-profiles" title="Location Profiles">

      <t>LoST uses location information in &lt;location> elements in requests and
        &lt;serviceBoundary> elements in responses. Such location information may be expressed
        in a variety of ways. This variety can cause interoperability problems where a request or
        response contains location information in a format not understood by the server or the
        client, respectively. To achieve interoperability, this document defines two
        mandatory-to-implement baseline location profiles to define the manner in which location
        information is transmitted. It is possible to standardize other profiles in the future. The
        baseline profiles are: <list style="hanging">

          <t hangText="geodetic-2d:"><vspace blankLines="0"/> a profile for two-dimensional geodetic
            location information, as described in <xref target="geodetic-2d-profile"/>;.</t>

          <t hangText="civic:"><vspace blankLines="0"/> a profile consisting of civic address
            location information, as described in <xref target="basic-civic-profile"/>.</t>

        </list></t>

      <t>Requests and responses containing &lt;location> or &lt;serviceBoundary> elements
        MUST contain location information in exactly one of the two baseline profiles, in addition
        to zero or more additional profiles. The ordering of location information indicates a
        preference on the part of the sender.</t>

      <t>Standards action is required for defining new profiles. A location profile MUST define:
          <list style="numbers">
          <t>The token identifying it in the LoST location profile registry.</t>

          <t>The formal definition of the XML to be used in requests, i.e., an enumeration and
            definition of the XML child elements of the &lt;location&gt; element.</t>

          <t>The formal definition of the XML to be used in responses, i.e., an enumeration and
            definition of the XML child elements of the &lt;serviceBoundary&gt; element.</t>

          <t>The declaration of whether geodetic-2d or civic is to be used as the baseline profile.
            It is necessary to explicitly declare the baseline profile as future profiles may be
            combinations of geodetic and civic location information.</t>

        </list></t>

      <section anchor="location-profile-usage" title="Location Profile Usage">

        <t>A location profile is identified by a token in an <xref target="profile-registry"
            >IANA-maintained registry</xref>. Clients send location information compliant with a
          location profile, and servers respond with location information compliant with that same
          location profile.</t>

        <t>When a LoST client sends a &lt;findService&gt; request that provides location
          information, it includes one or more &lt;location> elements. A &lt;location>
          element carries an optional 'profile' attribute that indicates the location format of the
          child elements. A client may obtain location information that does not conform to a
          profile it recognizes, or it may not have the capability to map XML to profiles. In that
          case, a client MAY omit the profile attribute and the server should interpret the XML
          location data to the best of its ability, returning a <spanx style="verb"
            >locationProfileUnrecognized</spanx> error if it is unable to do so.</t>

        <t>The concept of location profiles is described in <xref target="location-profiles"/>. With
          the ability to specify more than one &lt;location> element, the client is able to
          convey location information for multiple location profiles in the same request.</t>

        <t>When a LoST server sends a response that contains location information, it uses the
          &lt;serviceBoundary&gt; elements much like the client uses the
          &lt;location&gt; elements. Each &lt;serviceBoundary&gt; element contains
          location information conforming to the location profile specified in the 'profile'
          attribute. A response MAY contain multiple mappings or boundaries for the different
          &lt;location> elements, subject to the restrictions below.</t>

        <t>Using the location profiles defined in this document, the following rules ensure
          interoperability between clients and servers: <list style="numbers">

            <t>A client MUST be capable of understanding the response for the baseline profiles it
              used in the request.</t>

            <t>If a client sends location information conformant to any location profile other than
              the ones described in this document, it MUST also send, in the same request, location
              information conformant to one of the baseline profiles. Otherwise, the server might
              not be able to understand the request.</t>

            <t>A client MUST NOT send multiple &lt;location&gt; objects that are derived
              from different baseline profiles. In other words, a client MUST only send location
              objects according to the same baseline profile in a query, but it MAY contain a
              location element following a baseline profile in addition to some other profile.</t>

            <t>If a client has both location information primarily of geodetic nature and location
              information primarily of a civic nature, it MUST send separate requests containing
              each type of location information.</t>

            <t>There can only be one instance of each location profile in a query.</t>

            <t>Servers MUST implement all profiles described in this document.</t>

            <t>A server uses the first-listed location profile that it understands and ignores the
              others.</t>

            <t>If a server receives a request that only contains location information using profiles
              it does not understand, the server responds with a <xref target="errors"
                >&lt;locationProfileError&gt;</xref>.</t>

            <t>The &lt;serviceBoundary> element MUST use the same location profile that was used
              to retrieve the answer and indicates which profile has been used with the 'profile'
              attribute.</t>

          </list> These rules enable the use of location profiles not yet specified, while ensuring
          baseline interoperability. Take, for example, this scenario illustrated in Figure 15 and
          16. Client X has had its firmware upgraded to support the
          'not-yet-standardized-prism-profile' location profile. Client X sends location information
          to Server Y, which does not understand the 'not-yet-standardized-prism-profile' location
          profile. If Client X also sends location information using the geodetic-2D baseline
          profile, then Server Y will still be able to understand the request and provide an
          understandable response, though with location information that might not be as precise or
          expressive as desired. This is possible because both Client X and Server Y understand the
          baseline profile.</t>
        <t>
          <figure anchor="findService-geo-uber3d.xml"
            title="Example of a &lt;findServices> query with baseline
profile interoperability">
            <artwork xml:space="preserve">
<![CDATA[  
<?xml version="1.0" encoding="UTF-8"?>
<findService 
  xmlns="urn:ietf:params:xml:ns:lost1" 
  xmlns:gml="http://www.opengis.net/gml"
  xmlns:gs="http://www.opengis.net/pidflo/1.0"
  recursive="true" 
  serviceBoundary="value">
  <location id="ABC 123" 
      profile="not-yet-standardized-prism-profile">
    <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
      <gs:base>
        <gml:Polygon>
          <gml:exterior>
            <gml:LinearRing>
              <gml:posList>
                42.556844 -73.248157 36.6
                42.656844 -73.248157 36.6
                42.656844 -73.348157 36.6
                42.556844 -73.348157 36.6
                42.556844 -73.248157 36.6
              </gml:posList>
            </gml:LinearRing>
          </gml:exterior>
        </gml:Polygon>
      </gs:base>
      <gs:height uom="urn:ogc:def:uom:EPSG::9001">
        2.4
      </gs:height>
    </gs:Prism>
  </location>
  <location id="DEF 345" profile="geodetic-2d">
    <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
      <gml:pos>42.656844 -73.348157</gml:pos>
    </gml:Point>
  </location>
  <service>urn:service:sos.police</service>
</findService>
]]></artwork>
          </figure>
        </t>

        <t>
          <figure anchor="findServiceResponse-geo-uber3d.xml"
            title="Example of a &lt;findServiceResponse> message with baseline
profile interoperability">
            <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse 
  xmlns="urn:ietf:params:xml:ns:lost1" 
  xmlns:p2="http://www.opengis.net/">
  <mapping 
    expires="2007-01-01T01:44:33Z"
    lastUpdated="2006-11-01T01:00:00Z"
    source="authoritative.example"
    sourceId="cf19bbb038fb4ade95852795f045387d">
    <displayName xml:lang="en">
      New York City Police Department
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary profile="geodetic-2d">
      <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
        <p2:exterior>
          <p2:LinearRing>
            <p2:pos>37.775 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4194</p2:pos>
          </p2:LinearRing>
        </p2:exterior>
      </p2:Polygon>
    </serviceBoundary>
    <uri>sip:nypd@example.com</uri> 
    <serviceNumber>911</serviceNumber>
  </mapping>
  <path>
    <via source="resolver.example"/>
    <via source="authoritative.example"/>
  </path>
  <locationUsed id="DEF 345"/>
</findServiceResponse>
]]></artwork>
          </figure>
        </t>
      </section>

      <section anchor="geodetic-2d-profile" title="Two-Dimensional Geodetic Profile">

        <t>The <spanx style="verb">geodetic-2d</spanx> location profile is identified by the token
            <spanx style="verb">geodetic-2d</spanx>. Clients and servers use this profile by placing
          the following location shapes into the &lt;serviceBoundary> or into the
          &lt;location> element (unless indicated otherwise): <list style="hanging">

            <t hangText="Point:"><vspace blankLines="0"/> The &lt;Point&gt; element is
              described in Section 5.2.1 of <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>.
              Section 5.2.1 of <xref target="I-D.ietf-geopriv-pdif-lo-profile"/> shows also the
              specification of a &lt;Point&gt; with either a two-dimensional position
              (latitude and longitude) or three-dimensional position (latitude, longitude, and
              altitude). A client MAY use the three-dimensional position, and servers MAY interpret
              a three-dimensional position as a two-dimensional position by ignoring the altitude
              value. A &lt;Point&gt; element is not placed into a &lt;serviceBoundary>
              element. </t>

            <t hangText="Polygon:"><vspace blankLines="0"/> The &lt;Polygon&gt; element is
              described in Section 5.2.2 of <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>. The
              restriction to 16 points for a polygon contained in Section 7.2.2 of <xref
                target="geo-shapes"/> is not applicable to this document. </t>

            <t hangText="Circle:"><vspace blankLines="0"/> The &lt;Circle&gt; element is
              described in Section 5.2.3 of <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>. </t>

            <t hangText="Ellipse:"><vspace blankLines="0"/> The &lt;Ellipse&gt; element is
              described in Section 5.2.4 of <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>.</t>

            <t hangText="ArcBand:"><vspace blankLines="0"/> The &lt;ArcBand&gt; element is
              described in Section 5.2.5 of <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>.</t>
          </list>
        </t>

        <t>When a client uses a &lt;Polygon&gt;, &lt;Circle&gt;,
          &lt;Ellipse&gt;, or &lt;ArcBand&gt; element within the
          &lt;location&gt; element, it is indicating that it will be satisfied by query
          results appropriate to any portion of the shape. It is left to the server to select an
          appropriate matching algorithm. A server MAY return multiple &lt;mapping&gt;
          elements if the shape extends across multiple service areas. Servers are not required to
          return all possible &lt;mapping&gt; elements to avoid denial-of-service attacks in
          which clients present queries that span a very large number of service boundaries (e.g.,
          presenting a shape covering all of the United States). </t>

        <t> In the case where the server does not return multiple &lt;mapping&gt; elements,
          but the shape extends across a service boundary, it is possible that the matching
          algorithm selected by the LoST server will return results that match a portion of the
          shape but do not match those specific to a particular point. A client may always select a
          point from within the shape to avoid this condition. The cases where it does not are
          generally those where it knows its own position only within the shape given. In emergency
          service use cases, that may result in the PSAP contacted at the URI provided by LoST being
          required to forward a call to one of its neighbors; this is an expected part of the
          overall emergency response system. In non-emergency service use cases, the service
          deployment model should take into account this issue as part of the provisioning model, as
          the combination of the data in the LoST server and the algorithm used for mapping
          determine which contact URIs are returned when shapes are used that overlap multiple
          service areas.</t>

        <t> As a general guideline, any deployed matching algorithm should ensure that the algorithm
          used does not needlessly return no results if there are valid results for any portion of
          the shape. If an authoritative server receives a query for which the area in the query
          overlaps the area for which the server has mapping information, then it MUST return either
          a mapping whose coverage area intersects the query area or a redirect to another server
          whose coverage area is a subset of the server's coverage area. </t>

        <t>When geodetic location information of this location profile is placed in the
          &lt;serviceBoundary&gt; element, then the elements with geospatial coordinates are
          alternative descriptions of the same service region, not additive geometries.</t>

      </section>

      <section anchor="basic-civic-profile" title="Basic Civic Profile">
        <t>The basic civic location profile is identified by the token 'civic'. Clients use this
          profile by placing a &lt;civicAddress&gt; element, defined in <xref
            target="RFC5139"/>, within the &lt;location&gt; element.</t>

        <t>Servers use this profile by placing a &lt;civicAddress&gt; element, defined in
            <xref target="RFC5139"/>, within the &lt;serviceBoundary&gt; element.</t>

        <t>A response MAY contain more than one &lt;serviceBoundary> element with profile
          'civic'. The purpose of allowing multiple &lt;serviceBoundary> elements is to be able
          to express more complex location shapes. Each &lt;serviceBoundary> element describes a
          set of civic addresses that fall within the service boundary, namely, all addresses that
          textually match the civic address elements provided, regardless of the value of other
          address elements. A location falls within the mapping's service boundary if it matches any
          of the &lt;serviceBoundary> elements. Hence, a response may contain multiple
          &lt;serviceBoundary> elements with civic and/or geodetic location profiles.</t>
      </section>

    </section>

    <!-- **************************************************************************************** -->
    <section anchor="error-codes" title="Errors, Warnings, and Redirects">

      <t>When a LoST server cannot fulfill a request completely, it can return either an error or a
        warning, depending on the severity of the problem. It returns an &lt;errors> element if
        no useful response can be returned for the query. It returns a &lt;warnings> element as
        part of another response element if it was able to respond in part, but the response may not
        be quite what the client had desired. For both elements, the 'source' attribute names the
        server that originally generated the error or warning, such as the authoritative server.
        Unless otherwise noted, all elements below can be either an error or a warning, depending on
        whether a default response, such as a mapping, is included.</t>

      <section anchor="errors" title="Errors">

        <t>LoST defines a pattern for errors, defined as &lt;errors&gt; elements 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 human-readable text. One or more
          such error elements are contained in the &lt;errors> element.</t>

        <t>The following errors follow this basic pattern: <list style="hanging">
            <t hangText="badRequest"><vspace blankLines="0"/>The server could not parse or otherwise
              understand a request, e.g., because the XML was malformed.</t>

            <t hangText="forbidden"><vspace blankLines="0"/>The server refused to send an answer.
              This generally only occurs for recursive queries, namely, if the client tried to
              contact the authoritative server and was refused.</t>

            <t hangText="internalError"><vspace blankLines="0"/>The server could not satisfy a
              request due to misconfiguration or other operational and non-protocol-related reasons.</t>

            <t hangText="locationProfileUnrecognized"><vspace blankLines="0"/>None of the profiles
              in the request were recognized by the server (see <xref target="location-profiles"/>).</t>

            <t hangText="locationInvalid"><vspace blankLines="0"/>The geodetic or civic location in
              the request was invalid. For example, the longitude or latitude values fall outside
              the acceptable ranges. </t>

            <t hangText="SRSInvalid"><vspace blankLines="0"/>The spatial reference system (SRS)
              contained in the location element was not recognized or does not match the location
              profile.</t>

            <t hangText="loop"><vspace blankLines="0"/>During a recursive query, the server was
              about to visit a server that was already in the server list in the &lt;path>
              element, indicating a request loop.</t>

            <t hangText="notFound"><vspace blankLines="0"/>The server could not find an answer to
              the query.</t>

            <t hangText="serverError"><vspace blankLines="0"/>An answer was received from another
              LoST server, but it could not be parsed or otherwise understood. This error occurs
              only for recursive queries.</t>

            <t hangText="serverTimeout"><vspace blankLines="0"/>A time out occurred before an answer
              was received.</t>

            <t hangText="serviceNotImplemented"><vspace blankLines="0"/>The requested service URN is
              not implemented and no substitution was available.</t>

          </list>
        </t>

        <t>An example is below: <figure anchor="errors-InternalError.xml"
            title="Example of an error response">
            <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1"
  source="resolver.example">
   <internalError message="Software bug." xml:lang="en"/>
</errors>
]]></artwork>
          </figure></t>

      </section>

      <section anchor="warnings" title="Warnings">

        <t>A response MAY contain zero or more warnings. This pattern defines a 'message' attribute
          containing human-readable text and an 'xml:lang' attribute denoting the language of the
          human-readable text. One or more such warning elements are contained in the
          &lt;warnings> element. To provide human-readable text in an appropriate language, the
          HTTP content negotiation capabilities (see <xref target="transport"/>) MAY be utilized by
          a server.</t>

        <t>This version of the specification defines the following warnings: <list style="hanging">

            <t hangText="locationValidationUnavailable"><vspace blankLines="0"/> The
              &lt;locationValidationUnavailable> element MAY be returned when a server wishes to
              notify a client that it cannot fulfill a location validation request. This warning
              allows a server to return mapping information while signaling this exception state.</t>

            <t hangText="serviceSubstitution"><vspace blankLines="0"/> The
              &lt;serviceSubstitution> element MAY be returned when a server was not able to
              fulfill a &lt;findService&gt; request for a given service URN. For example, a
              &lt;findService&gt; request with the 'urn:service:sos.police' service URN for
              a location in Uruguay may cause the LoST service to return a mapping for the
              'urn:service:sos' service URN since Uruguay does not make use of the sub-services
              police, fire, and ambulance. If this warning is returned, then the
              &lt;service&gt; element in the response provides information about the service
              URN that refers to the mapping. </t>

            <t hangText="defaultMappingReturned"><vspace blankLines="0"/> The
              &lt;defaultMappingReturned> element MAY be returned when a server was not able to
              fulfill a &lt;findService&gt; request for a given location but is able to
              respond with a default URI. For example, a nearby PSAP may be returned. </t>

          </list>
        </t>
        <t>An example of a warning is shown below: <figure
            anchor="findServiceResponse-geo-failure.xml" title="Example of a warning response">
            <artwork xml:space="preserve">
            <![CDATA[
 <?xml version="1.0" encoding="UTF-8"?>
 <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
   xmlns:p2="http://www.opengis.net/">
   <mapping
     expires="2007-01-01T01:44:33Z"
     lastUpdated="2006-11-01T01:00:00Z"
     source="authoritative.example"
     sourceId="fb8ed888433343b7b27865aeb38f3a99">
     <displayName xml:lang="en">
       New York City Police Department
     </displayName>
     <service>urn:service:sos.police</service>
     <serviceBoundary profile="geodetic-2d">
       <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
         <p2:exterior>
           <p2:LinearRing>
             <p2:pos>37.775 -122.4194</p2:pos>
             <p2:pos>37.555 -122.4194</p2:pos>
             <p2:pos>37.555 -122.4264</p2:pos>
             <p2:pos>37.775 -122.4264</p2:pos>
             <p2:pos>37.775 -122.4194</p2:pos>
           </p2:LinearRing>
         </p2:exterior>
       </p2:Polygon>
     </serviceBoundary>
     <uri>sip:nypd@example.com</uri>
     <serviceNumber>911</serviceNumber>
   </mapping>
   <warnings source="authoritative.example">
     <defaultMappingReturned
         message="Unable to determine PSAP for the given location;
             using default PSAP"
         xml:lang="en"/>
   </warnings>
   <path>
     <via source="resolver.example"/>
     <via source="authoritative.example"/>
   </path>
 </findServiceResponse>
            ]]></artwork>
          </figure></t>


      </section>

      <section anchor="redirects" title="Redirects">

        <t>A LoST server can respond indicating that the querier should redirect the query to
          another server, using the &lt;redirect> element. The element includes a 'target'
          attribute indicating the LoST application unique string (see <xref target="lost"/>) that
          the client SHOULD be contacting next, as well as the 'source' attribute indicating the
          server that generated the redirect response and a 'message' attribute explaining the
          reason for the redirect response. During a recursive query, a server receiving a
          &lt;redirect> response can decide whether it wants to follow the redirection or simply
          return the response to its upstream querier. The "expires" value in the response returned
          by the server handling the redirected query indicates the earliest time at which a new
          query might be needed (see Section 5.2). The query for the same tuple of location and
          service SHOULD NOT be directed to the server that gave redirect prior to that time.</t>

        <t>An example is below: <figure anchor="redirect.xml" title="Example of a redirect response">
            <artwork xml:space="preserve">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<redirect xmlns="urn:ietf:params:xml:ns:lost1"
  target="eastpsap.example"
  source="westpsap.example"
  message="We have temporarily failed over." xml:lang="en"/>
]]></artwork>
          </figure></t>

      </section>

    </section>
    <!-- **************************************************************************************** -->

    <section anchor="transport" title="LoST Transport: HTTP">

      <t>LoST needs an underlying protocol transport mechanism to carry requests and responses. This
        document defines the use of LoST over HTTP and LoST over HTTP-over-TLS. Client and server
        developers are reminded that full support of RFC 2616 HTTP facilities is expected. If LoST
        clients or servers re-implement HTTP, rather than using available servers or client code as
        a base, careful attention must be paid to full interoperability. Other transport mechanisms
        are left to future documents. The available transport mechanisms are determined through the
        use of the LoST U-NAPTR application. In protocols that support content type indication, LoST
        uses the media type application/lost+xml.</t>

      <t>When using HTTP <xref target="RFC2616"/> and HTTP-over-TLS <xref target="RFC2818"/>, LoST
        requests use the HTTP POST method. The HTTP request MUST use the Cache-Control response
        directive "no-cache" to disable HTTP-level caching even by caches that have been configured
        to return stale responses to client requests.</t>

      <t>All LoST responses, including those indicating a LoST warning or error, are carried in 2xx
        responses, typically 200 (OK). Other 2xx responses, in particular 203 (Non-authoritative
        information), may be returned by HTTP caches that disregard the caching instructions. 3xx,
        4xx, and 5xx HTTP response codes indicate that the HTTP request itself failed or was
        redirected; these responses do not contain any LoST XML elements. The 3xx responses are
        distinct from the redirects that are described in Section 13.3; the redirect operation in
          <xref target="redirects"/> occur after a LoST server processes the request. Where an
        HTTP-layer redirect will be general, a LoST server redirect as described in Section 13.3
        might be specific to a specific service or be the result of other processing by the LoST
        server. </t>

      <t>The HTTP URL is derived from the LoST server name via U-NAPTR application, as discussed
        above.</t>

    </section>

    <!-- **************************************************************************************** -->
    <section anchor="schema" title="Relax NG Schema">

      <t>This section provides the Relax NG schema used by the LoST protocol in the compact form.
        The verbose form is included in <xref target="schema-verbose"/>.</t>


      <t>
        <figure anchor="lost.rnc" title="RelaxNG schema">
          <artwork>
            <![CDATA[
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost1"

## 
##       Location-to-Service Translation (LoST) Protocol 

## 
##       A LoST XML instance has three request types, each with
##       a corresponding response type: find service, list services,
##       and get service boundary.
##     
start =
  findService
  | listServices
  | listServicesByLocation
  | getServiceBoundary
  | findServiceResponse
  | listServicesResponse
  | listServicesByLocationResponse
  | getServiceBoundaryResponse
  | errors
  | redirect

## 
##       The queries.
##     
div {
  findService =
    element findService {
      requestLocation,
      commonRequestPattern,
      attribute validateLocation {
        xsd:boolean >> a:defaultValue [ "false" ]
      }?,
      attribute serviceBoundary {
        ("reference" | "value") >> a:defaultValue [ "reference" ]
      }?,
      attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
    }
  listServices = element listServices { commonRequestPattern }
  listServicesByLocation =
    element listServicesByLocation {
      requestLocation,
      commonRequestPattern,
      attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
    }
  getServiceBoundary =
    element getServiceBoundary { serviceBoundaryKey, extensionPoint }
}

## 
##       The responses.
##     
div {
  findServiceResponse =
    element findServiceResponse {
      mapping+, locationValidation?, commonResponsePattern, locationUsed
    }
  listServicesResponse =
    element listServicesResponse { serviceList, commonResponsePattern }
  listServicesByLocationResponse =
    element listServicesByLocationResponse {
      serviceList, commonResponsePattern, locationUsed
    }
  getServiceBoundaryResponse =
    element getServiceBoundaryResponse {
      serviceBoundary, commonResponsePattern
    }
}

## 
##       A pattern common to some of the queries.
##     
div {
  commonRequestPattern = service, path?, extensionPoint
}

## 
##       A pattern common to responses.
##     
div {
  commonResponsePattern = warnings*, path, extensionPoint
}

## 
##       Location in Requests
##     
div {
  requestLocation =
    element location {
      attribute id { xsd:token },
      locationInformation
    }+
}

## 
##       Location Information
##     
div {
  locationInformation =
    extensionPoint+,
    attribute profile { xsd:NMTOKEN }?
}

## 
##       Service Boundary
##     
div {
  serviceBoundary = element serviceBoundary { locationInformation }+
}

## 
##       Service Boundary Reference
##     
div {
  serviceBoundaryReference =
    element serviceBoundaryReference {
      source, serviceBoundaryKey, extensionPoint
    }
  serviceBoundaryKey = attribute key { xsd:token }
}

## 
##       Path - 
##       Contains a list of via elements - 
##       places through which information flowed
##     
div {
  path =
    element path {
      element via { source, extensionPoint }+
    }
}

## 
##       Location Used
##     
div {
  locationUsed =
    element locationUsed {
      attribute id { xsd:token }
    }?
}

## 
##       Expires pattern
##     
div {
  expires =
    attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
}

## 
##       A QName list
##     
div {
  qnameList = list { xsd:QName* }
}

## 
##       A location-to-service mapping.
##     
div {
  mapping =
    element mapping {
      element displayName {
        xsd:string,
        attribute xml:lang { xsd:language }
      }*,
      service,
      (serviceBoundary | serviceBoundaryReference)?,
      element uri { xsd:anyURI }*,
      element serviceNumber {
        xsd:token { pattern = "[0-9*#]+" }
      }?,
      extensionPoint,
      expires,
      attribute lastUpdated { xsd:dateTime },
      source,
      attribute sourceId { xsd:token },
      message
    }
}

## 
##       Location validation
##     
div {
  locationValidation =
    element locationValidation {
      element valid { qnameList }?,
      element invalid { qnameList }?,
      element unchecked { qnameList }?,
      extensionPoint
    }
}

## 
##       Errors and Warnings Container.
##     
div {
  exceptionContainer =
    (badRequest?
     & internalError?
     & serviceSubstitution?
     & defaultMappingReturned?
     & forbidden?
     & notFound?
     & loop?
     & serviceNotImplemented?
     & serverTimeout?
     & serverError?
     & locationInvalid?
     & locationProfileUnrecognized?),
    extensionPoint,
    source
  errors = element errors { exceptionContainer }
  warnings = element warnings { exceptionContainer }
}

## 
##       Basic Exceptions
##     
div {
  
  ## 
  ##         Exception pattern.
  ##       
  basicException = message, extensionPoint
  badRequest = element badRequest { basicException }
  internalError = element internalError { basicException }
  serviceSubstitution = element serviceSubstitution { basicException }
  defaultMappingReturned =
    element defaultMappingReturned { basicException }
  forbidden = element forbidden { basicException }
  notFound = element notFound { basicException }
  loop = element loop { basicException }
  serviceNotImplemented =
    element serviceNotImplemented { basicException }
  serverTimeout = element serverTimeout { basicException }
  serverError = element serverError { basicException }
  locationInvalid = element locationInvalid { basicException }
  locationValidationUnavailable =
    element locationValidationUnavailable { basicException }
  locationProfileUnrecognized =
    element locationProfileUnrecognized {
      attribute unsupportedProfiles { xsd:NMTOKENS },
      basicException
    }
}

## 
##       Redirect.
##     
div {
  
  ## 
  ##         Redirect pattern
  ##       
  redirect =
    element redirect {
      attribute target { appUniqueString },
      source,
      message,
      extensionPoint
    }
}

## 
##       Some common patterns.
##     
div {
  message =
    (attribute message { xsd:token },
     attribute xml:lang { xsd:language })?
  service = element service { xsd:anyURI }?
  appUniqueString =
    xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
  source = attribute source { appUniqueString }
  serviceList =
    element serviceList {
      list { xsd:anyURI* }
    }
}

## 
##       Patterns for inclusion of elements from schemas in
##       other namespaces.
##     
div {
  
  ## 
  ##         Any element not in the LoST namespace.
  ##       
  notLost = element * - (ns1:* | ns1:*) { anyElement }
  
  ## 
  ##         A wildcard pattern for including any element
  ##         from any other namespace.
  ##       
  anyElement =
    (element * { anyElement }
     | attribute * { text }
     | text)*
  
  ## 
  ##         A point where future extensions
  ##         (elements from other namespaces)
  ##         can be added.
  ##       
  extensionPoint = notLost*
}
]]></artwork>
        </figure>
      </t>
    </section>

    <!-- **************************************************************************************** -->

    <section title="Internationalization Considerations">

      <t>The LoST protocol is mostly meant for machine-to-machine communications; 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
        &lt;displayName&gt; element and the 'message' attributes may be displayed to the end
        user, and they are thus complex types designed for this purpose.</t>
      <t>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.</t>

    </section>

    <!-- **************************************************************************************** -->

    <section anchor="iana" title="IANA Considerations">

      <section title="U-NAPTR Registrations" anchor="u-naptr">

        <t>This document registers the following U-NAPTR application service tag: <list
            style="empty">
            <list style="hanging">
              <t hangText="Application Service Tag:">LoST</t>
              <t hangText="Defining Publication:">The specification contained within this
              document.</t>
            </list>
          </list>
        </t>

        <t>This document registers the following U-NAPTR application protocol tags: <list
            style="symbols">
            <t>Application Protocol Tag: http <vspace blankLines="1"/> Defining Publication: <xref
                target="RFC2616">RFC 2616</xref>
            </t>

            <t>Application Protocol Tag: https <vspace blankLines="1"/> Defining Publication: <xref
                target="RFC2818">RFC 2818</xref>
            </t>
          </list>
        </t>
      </section>

      <section title="Content-Type Registration for 'application/lost+xml'">

        <t>This specification requests the registration of a new MIME type according to the
          procedures of RFC 4288 <xref target="RFC4288"/> and guidelines in RFC 3023 <xref
            target="RFC3023"/>.</t>

        <t>
          <list style="hanging">
            <t hangText="MIME media type name:">application </t>

            <t hangText="MIME subtype name:">lost+xml </t>

            <t hangText="Mandatory parameters:">none </t>

            <t hangText="Optional parameters:">charset<vspace blankLines="0"/> Indicates the
              character encoding of enclosed XML. </t>

            <t hangText="Encoding considerations:"> Uses XML, which can employ 8-bit characters,
              depending on the character encoding used. See RFC 3023 <xref target="RFC3023"/>,
              Section 3.2.</t>

            <t hangText="Security considerations:"> This content type is designed to carry LoST
              protocol payloads.</t>

            <t hangText="Interoperability considerations:">None</t>

            <t hangText="Published specification:">RFC 5222 </t>

            <t hangText="Applications that use this media type:"> Emergency and location-based
              systems </t>

            <t hangText="Additional information:">
              <list style="hanging">
                <t hangText="Magic Number:">None </t>

                <t hangText="File Extension:">.lostxml </t>

                <t hangText="Macintosh file type code:">'TEXT' </t>
              </list>
            </t>

            <t hangText="Personal and email address for further
			 information:">
              <vspace blankLines="0"/> Hannes Tschofenig, Hannes.Tschofenig@nsn.com </t>

            <t hangText="Intended usage:">LIMITED USE </t>

            <t hangText="Author:">
              <vspace blankLines="0"/> This specification is a work item of the IETF ECRIT working
              group, with mailing list address &lt;ecrit@ietf.org&gt;. </t>
            <t hangText="Change controller:">
              <vspace blankLines="0"/>The IESG &lt;iesg@ietf.org&gt; </t>
          </list>
        </t>
      </section>

      <section title="LoST Relax NG Schema Registration">

        <t>
          <list style="hanging">
            <t hangText="URI:">urn:ietf:params:xml:schema:lost1</t>
            <t hangText="Registrant Contact:">IETF ECRIT Working Group, Hannes Tschofenig
              (Hannes.Tschofenig@nsn.com).</t>
            <t hangText="Relax NG Schema:">The Relax NG schema to be registered is contained in
                <xref target="schema"/>. Its first line is <figure>
                <artwork><![CDATA[
default namespace = "urn:ietf:params:xml:ns:lost1"
]]></artwork>
              </figure> and its last line is<figure>
                <artwork><![CDATA[
}
]]></artwork>
              </figure>
            </t>
          </list>
        </t>
      </section>

      <section title="LoST Namespace Registration">
        <t>
          <list style="hanging">
            <t hangText="URI:">urn:ietf:params:xml:ns:lost1</t>

            <t hangText="Registrant Contact:">IETF ECRIT Working Group, Hannes Tschofenig
              (Hannes.Tschofenig@nsn.com).</t>

            <t hangText="XML:">
              <figure>
                <artwork><![CDATA[
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:lost1</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5222.txt">RFC5222</a>.</p>
</body>
</html>
END
]]></artwork>
              </figure>
            </t>
          </list>
        </t>
      </section>



      <section anchor="profile-registry" title="LoST Location Profile Registry">

        <t>This document creates a registry of location profile names for the LoST protocol. Profile
          names are XML tokens. This registry will operate in accordance with <xref target="RFC5226"
            >RFC 5226</xref>, Standards Action.</t>

        <t>
          <list style="hanging">
            <t hangText="geodetic-2d:"><vspace blankLines="0"/> Defined in <xref
                target="geodetic-2d-profile"/>.</t>

            <t hangText="civic:"><vspace blankLines="0"/> Defined in <xref
                target="basic-civic-profile"/>.</t>

          </list>
        </t>
      </section>
    </section>

    <!-- **************************************************************************************** -->

    <section anchor="security" title="Security Considerations">

      <t>There are several 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.</t>

      <t>To avoid an attacker modifying the query or its result, Transport Layer Security (TLS) MUST
        be implemented and SHOULD be used. Use is RECOMMENDED both for clients' queries to servers
        and for queries among servers; this latter recommendation is to help avoid LoST cache
        poisoning attacks by replacing answers given to caching LoST servers.</t>
      <t> The use of server identity checks with TLS, as described in Section 3.1 of <xref
          target="RFC2818"/>, is also RECOMMENDED. Omitting the server identity check allows an
        attacker to masquerade as a LoST server, so this approach should be used only when getting
        any answer, even from a potentially malicious LoST server, is preferred over closing the
        connection (and thus not getting any answer at all). The host name compared against the
        server certificate is the host name in the URI, not the DNS name used as input to NAPTR
        resolution. </t>

      <t>Note that the security considerations in <xref target="RFC3958"/> recommend comparing the
        input of NAPTR resolution to the certificate, not the output (host name in the URI). This
        approach was not chosen because in emergency service use cases, it is likely that
        deployments will see a large number of inputs to the U-NAPTR algorithm resolving to a single
        server, typically run by a local emergency services authority. In this case, checking the
        input to the NAPTR resolution against the certificates provided by the LoST server would be
        impractical, as the list of organizations using it would be large, subject to rapid change,
        and unknown to the LoST server operator. </t>
      <t> The use of server identity does leave open the possibility of DNS-based attacks, as the
        NAPTR records may be altered by an attacker. The attacks include, for example, interception
        of DNS packets between the client and the recursive name server, DNS cache poisoning, and
        intentional modifications by the recursive name server; see <xref target="RFC3833"/> for
        more comprehensive discussion. </t>
      <t> DNS Security (DNSSEC) <xref target="RFC4033"/> can be used to protect against these
        threats. While DNSSEC is incompletely deployed, users should be aware of the risk,
        particularly when they are requesting NAPTR records in environments where the local
        recursive name server, or the network between the client and the local recursive name
        server, is not considered trustworthy.</t>

      <t>LoST deployments that are unable to use DNSSEC and unwilling to trust DNS resolution
        without DNSSEC cannot use the NATPR-based discovery of LoST servers as is. When suitable
        configuration mechanisms are available, one possibility is to configure the LoST server URIs
        (instead of the domain name to be used for NAPTR resolution) directly. Future specifications
        for applying LoST in non-emergency services may also specify additional discovery mechanisms
        and name matching semantics.</t>

      <t>Generally, LoST servers will not need to authenticate or authorize clients presenting
        mapping queries. If they do, an authentication of the underlying transport mechanism, such
        as HTTP basic and digest authentication, MAY be used. Basic authentication SHOULD only be
        used in combination with TLS. </t>

      <t>A more detailed description of threats and security requirements is provided in <xref
          target="RFC5069"/>. The threats and security requirements in non-emergency service uses of
        LoST may be considerably different from those described here. For example, an attacker might
        seek monetary benefit by returning service mapping information that directed users to
        specific service providers. Before deploying LoST in new contexts, a thorough analysis of
        the threats and requirements specific to that context should be undertaken and decisions
        made on the appropriate mitigations. </t>

    </section>

    <!--
    ****************************************************************************************
    -->
    <section title="Acknowledgments">

      <t>For the acknowledgments to the initial LoST version please refer to RFC 5222 <xref
          target="RFC5222"/>. </t>

      <t>We would like to thank the following persons for their review comments to this revised
        version of LoST: Avery Penniston.</t>
    </section>

  </middle>
  <back>
    <references title="Normative References"> &RFC2119; <!-- &RFC2434; --> &RFC5222;
        <reference anchor="RFC5226">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
          <author initials="T." surname="Narten" fullname="T. Narten">
            <organization/>
          </author>
          <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
            <organization/>
          </author>
          <date year="2008" month="May"/>
          <abstract>
            <t>Many protocols make use of identifiers consisting of constants and other well-known
              values. Even after a protocol has been defined and deployment has begun, new values
              may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or
              authentication transform for IPsec). To ensure that such quantities have consistent
              values and interpretations across all implementations, their assignment must be
              administered by a central authority. For IETF protocols, that role is provided by the
              Internet Assigned Numbers Authority (IANA).</t>
            <t> In order for IANA to manage a given namespace prudently, it needs guidelines
              describing the conditions under which new values can be assigned or when modifications
              to existing values can be made. If IANA is expected to play a role in the management
              of a namespace, IANA must be given clear and concise instructions describing that
              role. This document discusses issues that should be considered in formulating a policy
              for assigning values to a namespace and provides guidelines for authors on the
              specific text that must be included in documents that place demands on IANA.</t>
            <t> This document obsoletes RFC 2434. This document specifies an Internet Best Current
              Practices for the Internet Community, and requests discussion and suggestions for
              improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="26"/>
        <seriesInfo name="RFC" value="5226"/>
        <format type="TXT" octets="66160" target="ftp://ftp.isi.edu/in-notes/rfc5226.txt"/>
      </reference> &RFC2616; &RFC2818; &RFC3023; &rfc4119; &RFC4288;
      &RFC4848; <!--&I-D.ietf-ecrit-service-urn; -->
      <!--&I-D.ietf-geopriv-revised-civic-lo;-->
      <reference anchor="RFC5031">
        <front>
          <title>A Uniform Resource Name (URN) for Emergency and Other Well-Known Services</title>
          <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
            <organization/>
          </author>
          <date year="2008" month="January"/>
          <abstract>
            <t>The content of many communication services depends on the context, such as the user's
              location. We describe a 'service' URN that allows well-known context-dependent
              services that can be resolved in a distributed manner to be identified. Examples
              include emergency services, directory assistance, and call-before-you-dig hot lines.
              [STANDARDS TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5031"/>
        <format type="TXT" octets="32960" target="ftp://ftp.isi.edu/in-notes/rfc5031.txt"/>
      </reference>
      <reference anchor="RFC5139">
        <front>
          <title>Revised Civic Location Format for Presence Information Data Format Location Object
            (PIDF-LO)</title>
          <author initials="M." surname="Thomson" fullname="M. Thomson">
            <organization/>
          </author>
          <author initials="J." surname="Winterbottom" fullname="J. Winterbottom">
            <organization/>
          </author>
          <date year="2008" month="February"/>
          <abstract>
            <t>This document defines an XML format for the representation of civic location. This
              format is designed for use with Presence Information Data Format Location Object
              (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is
              based on the civic address definition in PIDF-LO, but adds several new elements based
              on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a
              hierarchy to address complex road identity schemes. The format also includes support
              for the xml:lang language tag and restricts the types of elements where appropriate.
              [STANDARDS TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5139"/>
        <format type="TXT" octets="27470" target="ftp://ftp.isi.edu/in-notes/rfc5139.txt"/>
      </reference>
      <reference anchor="GML">
        <front>
          <title>Geographic information - Geography Markup Language (GML)</title>
          <author fullname="S. Cox" initials="S." surname="Cox">
            <organization/>
            <address>
<email/>
</address>
          </author>
          <author fullname="P. Daisey" initials="P." surname="Daisey">
            <organization/>
            <address>
<email/>
</address>
          </author>
          <author fullname="R. Lake" initials="R." surname="Lake">
            <organization/>
            <address>
<email/>
</address>
          </author>
          <author fullname="C. Portele" initials="C." surname="Portele">
            <organization/>
            <address>
<email/>
</address>
          </author>
          <author fullname="A. Whiteside" initials="A." surname="Whiteside">
            <organization/>
            <address>
<email/>
</address>
          </author>
          <date year="2004" month="April"/>
        </front>
        <seriesInfo name="OGC Standard" value="OpenGIS 03-105r1"/>
        <format type="PDF" target="http://portal.opengeospatial.org/files/?artifact_id=4700"/>
      </reference>
      <reference anchor="geo-shapes">
        <front>
          <title>GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task
            Force (IETF)</title>
          <author fullname="C. Reed" initials="C." surname="Reed">
            <organization/>
            <address>
<email/>
</address>
          </author>
          <author fullname="M. Thomson" initials="M." surname="Thomson">
            <organization/>
            <address>
<email/>
</address>
          </author>
          <date year="2006" month="December"/>
        </front>
        <seriesInfo name="Candidate OpenGIS Implementation Specification" value=""/>
        <format type="PDF" target="http://portal.opengeospatial.org/files/?artifact_id=17591"/>
      </reference>
    </references>
    <references title="Informative References">
      <!--&I-D.ietf-geopriv-pdif-lo-profile;-->
      <reference anchor="I-D.ietf-geopriv-pdif-lo-profile">
        <front>
          <title>GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations</title>
          <author initials="J" surname="Winterbottom" fullname="James Winterbottom">
            <organization/>
          </author>
          <author initials="M" surname="Thomson" fullname="Martin Thomson">
            <organization/>
          </author>
          <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
            <organization/>
          </author>
          <date month="February" day="19" year="2008"/>
          <abstract>
            <t>The Presence Information Data Format Location Object (PIDF-LO) specification provides
              a flexible and versatile means to represent location information. There are, however,
              circumstances that arise when information needs to be constrained in how it is
              represented. In these circumstances the range of options that need to be implemented
              are reduced. There is growing interest in being able to use location information
              contained in a PIDF-LO for routing applications. To allow successful interoperability
              between applications, location information needs to be normative and more tightly
              constrained than is currently specified in the RFC 4119 (PIDF-LO). This document makes
              recommendations on how to constrain, represent and interpret locations in a PIDF-LO.
              It further recommends a subset of GML that is mandatory to implement by applications
              involved in location based routing.</t>
          </abstract>
        </front>
        <seriesInfo name="Work in" value="Progress"/>
        <format type="TXT"
          target="http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-11.txt"/>
      </reference> &RFC3261; &RFC3921; &RFC3966; <!--&I-D.ietf-ecrit-security-threats; -->
      <reference anchor="RFC5069">
        <front>
          <title>Security Threats and Requirements for Emergency Call Marking and Mapping</title>
          <author initials="T." surname="Taylor" fullname="T. Taylor">
            <organization/>
          </author>
          <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
            <organization/>
          </author>
          <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
            <organization/>
          </author>
          <author initials="M." surname="Shanmugam" fullname="M. Shanmugam">
            <organization/>
          </author>
          <date year="2008" month="January"/>
          <abstract>
            <t>This document reviews the security threats associated with the marking of signalling
              messages to indicate that they are related to an emergency, and with the process of
              mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety
              Answering Points (PSAPs). This mapping occurs as part of the process of routing
              emergency calls through the IP network.</t>
            <t> Based on the identified threats, this document establishes a set of security
              requirements for the mapping protocol and for the handling of emergency-marked calls.
              This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5069"/>
        <format type="TXT" octets="26230" target="ftp://ftp.isi.edu/in-notes/rfc5069.txt"/>
      </reference>
      <!--&I-D.ietf-ecrit-requirements; -->
      <reference anchor="RFC5012">
        <front>
          <title>Requirements for Emergency Context Resolution with Internet Technologies</title>
          <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
            <organization/>
          </author>
          <author initials="R." surname="Marshall" fullname="R. Marshall">
            <organization/>
          </author>
          <date year="2008" month="January"/>
          <abstract>
            <t>This document defines terminology and enumerates requirements for the context
              resolution of emergency calls placed by the public using voice-over-IP (VoIP) and
              general Internet multimedia systems, where Internet protocols are used end to end.
              This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5012"/>
        <format type="TXT" octets="54599" target="ftp://ftp.isi.edu/in-notes/rfc5012.txt"/>
      </reference>
      <!--&I-D.ietf-ecrit-mapping-arch;-->
      <reference anchor="I-D.ietf-ecrit-mapping-arch">
        <front>
          <title>Location-to-URL Mapping Architecture and Framework</title>
          <author initials="H" surname="Schulzrinne" fullname="Henning Schulzrinne">
            <organization/>
          </author>
          <date month="September" day="29" year="2007"/>
          <abstract>
            <t>This document describes an architecture for a global, scalable, resilient and
              administratively distributed system for mapping geographic location information to
              URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes
              well-known approaches found in hierarchical lookup systems such as DNS.</t>
          </abstract>
        </front>
        <seriesInfo name="Work in" value="Progress"/>
        <format type="TXT"
          target="http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt"/>
      </reference> &RFC4033; <!-- &I-D.ietf-ecrit-phonebcp; -->
      <reference anchor="I-D.ietf-ecrit-phonebcp">
        <front>
          <title>Best Current Practice for Communications Services in support of Emergency Calling</title>
          <author initials="B" surname="Rosen" fullname="Brian Rosen">
            <organization/>
          </author>
          <author initials="J" surname="Polk" fullname="James Polk">
            <organization/>
          </author>
          <date month="February" day="25" year="2008"/>
          <abstract>
            <t>The IETF and other standards organization have efforts targeted at standardizing
              various aspects of placing emergency calls on IP networks. This memo describes best
              current practice on how devices, networks and services should use such standards to
              make emergency calls.</t>
          </abstract>
        </front>
        <seriesInfo name="Work in" value="Progress"/>
        <format type="TXT"
          target="http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-04.txt"/>
      </reference> &RFC3958; &RFC3833; <reference anchor="URL_for_examples"
        target="http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/RelaxNG">
        <front>
          <title/>
          <!-- The title's extraneous quote marks in the text ouput will be removed before 
	    publication, unless you want to add a title to this reference. -->
          <author>
            <organization/>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="RFC5223">

        <front>

          <title> Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host
            Configuration Protocol (DHCP) </title>

          <author initials="H" surname="Schulzrinne" fullname="Henning Schulzrinne">
            <organization/>
          </author>

          <author initials="J" surname="Polk" fullname="James Polk">
            <organization/>
          </author>

          <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
            <organization/>
          </author>
          <date month="August" year="2008"/>

          <abstract>

            <t> The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol
              for mapping service identifiers and geospatial or civic location information to
              service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere
              but a placement closer to the end host, e.g., in the access network, is desireable.
              Such a LoST server placement provides benefits in disaster situations with
              intermittent network connectivity regarding the resiliency of emergency service
              communication. This document describes how a LoST client can discover a LoST server
              using the Dynamic Host Configuration Protocol (DHCP). </t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5223"/>
        <format type="TXT"
          target="http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-03.txt"/>
      </reference>
    </references>

    <section title="Changes from RFC 5222">

      <t>
        <list style="empty">

          <t>-00: Based on RFC 5222 the following changes were made: <list style="symbols">
              <t>New terminology introduced for "location validation". Still necessary to
                double-check it with the latest terms used in NENA.</t>
              <t>Editorial changes in Section 1 regarding service boundary hints. </t>
              <t>Clarified in Section 3 that service numbers are provided in the a
                &lt;findServiceResponse> message rather than in a separate message.</t>
              <t>Provided additional description in Section 5.1 regarding the 'lastUpdated'
                attribute and when a new mapping is created. </t>
              <t>Added a note about the usage of the NO-EXPIRATION value in Section 5.2.</t>
              <t>Fixed a wrong statement in Section 11 saying that the &lt;via&gt; elements
                are optional in the &lt;listServicesByLocationResponse&gt; message. They are
                mandatory.</t>
              <t>Included a clarification in Section 12.3 about why a response may contain more than
                one &lt;serviceBoundary> element.</t>
            </list></t>
          <t>The following changes are pending and require discussion on the list: <list
              style="symbols">
              <t>Removal of the &lt;serviceSubstitution&gt; warning element since the
                functionality is already accomplished by including the &lt;service&gt;
                element with the substituted service URN. </t>
              <t>Allowing the &lt;serviceBoundary&gt; element to contain location of
                profiles that were not included in the request. Example: Request with civic location
                information and response with geodetic service boundary.</t>
              <t>Description of how load balancing / alternate routing is accomplished.</t>
              <t>Inclusion of a contact info for error reporting in case there are failures.</t>
              <t>Provide additional description regarding the service boundary matching when the
                civic location profile is used.</t>
            </list></t>
        </list>
      </t>
    </section>

    <section anchor="schema-verbose" title="Non-Normative RELAX NG Schema in
XML Syntax">



      <t>
        <figure anchor="lost.rng">
          <artwork><![CDATA[
<?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 (LoST) Protocol

      A LoST XML instance has three request types, each with
      a corresponding response type: find service, list services,
      and get service boundary.
    </a:documentation>
    <choice>
      <ref name="findService"/>
      <ref name="listServices"/>
      <ref name="listServicesByLocation"/>
      <ref name="getServiceBoundary"/>
      <ref name="findServiceResponse"/>
      <ref name="listServicesResponse"/>
      <ref name="listServicesByLocationResponse"/>
      <ref name="getServiceBoundaryResponse"/>
      <ref name="errors"/>
      <ref name="redirect"/>
    </choice>
	</start>

  <div>
    <a:documentation>
      The queries.
    </a:documentation>

    <define name="findService">
      <element name="findService">
        <ref name="requestLocation"/>
        <ref name="commonRequestPattern"/>
        <optional>
          <attribute name="validateLocation">
            <data type="boolean"/>
            <a:defaultValue>false</a:defaultValue>
          </attribute>
        </optional>
        <optional>
          <attribute name="serviceBoundary">          
            <choice>
              <value>reference</value>
              <value>value</value>
            </choice>
            <a:defaultValue>reference</a:defaultValue>
          </attribute>
        </optional>
        <optional>
          <attribute name="recursive">
            <data type="boolean"/>
              <a:defaultValue>false</a:defaultValue>
          </attribute>
        </optional>
      </element>
    </define>

    <define name="listServices">
      <element name="listServices">
        <ref name="commonRequestPattern"/>
      </element>
    </define>

    <define name="listServicesByLocation">
      <element name="listServicesByLocation">
        <ref name="requestLocation"/>
        <ref name="commonRequestPattern"/>
        <optional>
          <attribute name="recursive">
            <data type="boolean"/>
            <a:defaultValue>true</a:defaultValue>
          </attribute>
        </optional>
      </element>
    </define>
    
    <define name="getServiceBoundary">
      <element name="getServiceBoundary">
        <ref name="serviceBoundaryKey"/>
        <ref name="extensionPoint"/>
      </element>
    </define>

  </div>

  <div>
    <a:documentation>
      The responses.
    </a:documentation>


    <define name="findServiceResponse">
      <element name="findServiceResponse">
        <oneOrMore>
          <ref name="mapping"/>
        </oneOrMore>
        <optional>
          <ref name="locationValidation"/>
        </optional>
        <ref name="commonResponsePattern"/>
        <ref name="locationUsed"/>
      </element>
    </define>


    <define name="listServicesResponse">
      <element name="listServicesResponse">
        <ref name="serviceList"/>
        <ref name="commonResponsePattern"/>        
      </element>
    </define>

    
    <define name="listServicesByLocationResponse">
      <element name="listServicesByLocationResponse">
        <ref name="serviceList"/>
        <ref name="commonResponsePattern"/>
        <ref name="locationUsed"/>
      </element>
    </define>
    
    <define name="getServiceBoundaryResponse">
      <element name="getServiceBoundaryResponse">
        <ref name="serviceBoundary"/>
        <ref name="commonResponsePattern"/>
      </element>
    </define>

  </div>

  <div>
    <a:documentation>
      A pattern common to some of the queries.
    </a:documentation>

    <define name="commonRequestPattern">
      <ref name="service"/>
      <optional>
        <ref name="path"/>  
      </optional>
      <ref name="extensionPoint"/>
    </define>
  </div>
  
  <div>
    <a:documentation>
      A pattern common to responses.
    </a:documentation>
    
    <define name="commonResponsePattern">
      <zeroOrMore>
        <ref name="warnings"/>
      </zeroOrMore>
      <ref name="path"/>
      <ref name="extensionPoint"/>      
    </define>
  </div>
  
  <div>
    <a:documentation>
      Location in Requests
    </a:documentation>
    
    <define name="requestLocation">
      <oneOrMore>
        <element name="location">
          <attribute name="id">
            <data type="token"/>  
          </attribute>
          <ref name="locationInformation"/>
        </element>
      </oneOrMore>
    </define>
  </div>

  <div>
    <a:documentation>
      Location Information
    </a:documentation>

    <define name="locationInformation">
      <oneOrMore>
        <ref name="extensionPoint"/>
      </oneOrMore>
      <optional>
        <attribute name="profile">
          <data type="NMTOKEN"/>
        </attribute>
      </optional>
    </define>
  </div>

  <div>
    <a:documentation>
      Service Boundary
    </a:documentation>

    <define name="serviceBoundary">
      <oneOrMore>
        <element name="serviceBoundary">
          <ref name="locationInformation"/>
        </element>
      </oneOrMore>
    </define>
  </div>

  <div>
    <a:documentation>
      Service Boundary Reference
    </a:documentation>

    <define name="serviceBoundaryReference">
      
      <element name="serviceBoundaryReference">
        <ref name="source"/>
        <ref name="serviceBoundaryKey"/>
        <ref name="extensionPoint"/>
      </element>
    </define>

    <define name="serviceBoundaryKey">
      <attribute name="key">
        <data type="token"/> 
      </attribute>
    </define>
    
  </div>
  
  <div>
    <a:documentation>
      Path - 
      Contains a list of via elements - 
      places through which information flowed
    </a:documentation>

    <define name="path">
      <element name="path">
        <oneOrMore>
          <element name="via">
            <ref name="source"/>
            <ref name="extensionPoint"/>
          </element>
        </oneOrMore>
      </element>
    </define>
  </div>
  
  <div>
    <a:documentation>
      Location Used
    </a:documentation>
    
    <define name="locationUsed">
      <optional>
        <element name="locationUsed">
          <attribute name="id">
            <data type="token"/>
          </attribute>
        </element>
      </optional>
    </define>
  </div>

  <div>
    <a:documentation>
      Expires pattern
    </a:documentation>

    <define name="expires">
      <attribute name="expires">
        <choice>
          <data type="dateTime"/>
          <value>NO-CACHE</value>
          <value>NO-EXPIRATION</value>
        </choice>
      </attribute>
    </define>
  </div>

  <div>
    <a:documentation>
      A QName list
    </a:documentation>

    <define name="qnameList">
      <list>
        <zeroOrMore>
          <data type="QName"/>
        </zeroOrMore>
      </list>
    </define>
  </div>

  <div>
    <a:documentation>
      A location-to-service mapping.
    </a:documentation>

    <define name="mapping">
      <element name="mapping">
        <zeroOrMore>
          <element name="displayName">
            <data type="string"/>
            <attribute name="xml:lang">
              <data type="language"/>
            </attribute>
          </element>
        </zeroOrMore>
        <ref name="service"/>
        <optional>
          <choice>
            <ref name="serviceBoundary"/>
            <ref name="serviceBoundaryReference"/>
          </choice>
        </optional>
        <zeroOrMore>
          <element name="uri">
            <data type="anyURI"/>
          </element>
        </zeroOrMore>
        <optional>
          <element name="serviceNumber">
            <data type="token">
              <param name="pattern">[0-9*#]+</param>
            </data>
          </element>
        </optional>
        <ref name="extensionPoint"/>
        <ref name="expires"/>
        <attribute name="lastUpdated">
          <data type="dateTime"/>
        </attribute>
        <ref name="source"/>
        <attribute name="sourceId">
          <data type="token"/>
        </attribute>
        <ref name="message"/>
      </element>
    </define>

  </div>
  
  <div>
    <a:documentation>
      Location validation
    </a:documentation>
    
    <define name="locationValidation">
      <element name="locationValidation">
        <optional>
          <element name="valid">
            <ref name="qnameList"/>
          </element>
        </optional>
        <optional>
          <element name="invalid">
            <ref name="qnameList"/>
          </element>
        </optional>
        <optional>
          <element name="unchecked">
            <ref name="qnameList"/>
          </element>
        </optional>        
        <ref name="extensionPoint"/>
      </element>
    </define>
  </div>
  
  <div>
    <a:documentation>
      Errors and Warnings Container.
    </a:documentation>
    
    <define name="exceptionContainer">
      <interleave>
        <optional>
          <ref name="badRequest"/>
        </optional>
        <optional>
          <ref name="internalError"/>
        </optional>
        <optional>
          <ref name="serviceSubstitution"/>
        </optional>
        <optional>
          <ref name="defaultMappingReturned"/>
        </optional>
        <optional>
          <ref name="forbidden"/>
        </optional>
        <optional>
          <ref name="notFound"/>
        </optional>
        <optional>
          <ref name="loop"/>
        </optional>
        <optional>
          <ref name="serviceNotImplemented"/>
        </optional>
        <optional>
          <ref name="serverTimeout"/>
        </optional>
        <optional>
          <ref name="serverError"/>
        </optional>
        <optional>
          <ref name="locationInvalid"/>
        </optional>
        <optional>
          <ref name="locationProfileUnrecognized"/>
        </optional>
      </interleave>
      <ref name="extensionPoint"/>
      <ref name="source"/>
    </define>
    
    <define name="errors">
      <element name="errors">
        <ref name="exceptionContainer"/>  
      </element>
    </define>

    <define name="warnings">
      <element name="warnings">
        <ref name="exceptionContainer"/>  
      </element>
    </define>
    
  </div>
  
  <div>
    <a:documentation>
      Basic Exceptions
    </a:documentation>

    <define name="basicException">
      <a:documentation>
        Exception pattern.
      </a:documentation>
      <ref name="message"/>
      <ref name="extensionPoint"/>
    </define>

    <define name="badRequest">
      <element name="badRequest">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="internalError">
      <element name="internalError">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="serviceSubstitution">
      <element name="serviceSubstitution">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="defaultMappingReturned">
      <element name="defaultMappingReturned">
        <ref name="basicException"/>
      </element>
    </define>
    
    <define name="forbidden">
      <element name="forbidden">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="notFound">
      <element name="notFound">
        <ref name="basicException"/>
      </element>
    </define>
    
    <define name="loop">
      <element name="loop">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="serviceNotImplemented">
      <element name="serviceNotImplemented">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="serverTimeout">
      <element name="serverTimeout">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="serverError">
      <element name="serverError">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="locationInvalid">
      <element name="locationInvalid">
        <ref name="basicException"/>
      </element>
    </define>
    
    <define name="locationValidationUnavailable">
      <element name="locationValidationUnavailable">
        <ref name="basicException"/>
      </element>
    </define>

    <define name="locationProfileUnrecognized">
      <element name="locationProfileUnrecognized">
        <attribute name="unsupportedProfiles">
          <data type="NMTOKENS"/>
        </attribute>
        <ref name="basicException"/>
      </element>
    </define>

  </div>

  <div>
    <a:documentation>
      Redirect.
    </a:documentation>

    <define name="redirect">
      <a:documentation>
        Redirect pattern
      </a:documentation>
      <element name="redirect">
        <attribute name="target">
          <ref name="appUniqueString"/>
        </attribute>
        <ref name="source"/>
        <ref name="message"/>
        <ref name="extensionPoint"/>
      </element>
    </define>

  </div>

  <div>
    <a:documentation>
      Some common patterns.
    </a:documentation>

    <define name="message">
      <optional>
        <group>
          <attribute name="message">
            <data type="token"/>
          </attribute>
          <attribute name="xml:lang">
            <data type="language"/>
          </attribute>
        </group>
      </optional>
    </define>
    
    <define name="service">
      <optional>
        <element name="service">
          <data type="anyURI"/>
        </element>
      </optional>
    </define>
    
    <define name="appUniqueString">
      <data type="token">
        <param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
      </data>
    </define>
    
    <define name="source">
      <attribute name="source">
        <ref name="appUniqueString"/>
      </attribute>
    </define>
    
    <define name="serviceList">
      <element name="serviceList">
        <list>
          <zeroOrMore>
            <data type="anyURI"/>
          </zeroOrMore>
        </list>
      </element>
    </define>    
    
  </div>

  <div>
    <a:documentation>
      Patterns for inclusion of elements from schemas in
      other namespaces.
    </a:documentation>

    <define name="notLost">
      <a:documentation>
        Any element not in the LoST namespace.
      </a:documentation>
      <element>
        <anyName>
          <except>
            <nsName ns="urn:ietf:params:xml:ns:lost1"/>
            <nsName/>
          </except>
        </anyName>
        <ref name="anyElement"/>
      </element>
    </define>


    <define name="anyElement">
      <a:documentation>
        A wildcard pattern for including any element
        from any other namespace.
      </a:documentation>
      <zeroOrMore>
        <choice>
          <element>
            <anyName/>
            <ref name="anyElement"/>
          </element>
          <attribute>
            <anyName/>
          </attribute>
          <text/>
        </choice>
      </zeroOrMore>
    </define>

    <define name="extensionPoint">
      <a:documentation>
        A point where future extensions
        (elements from other namespaces)
        can be added.
      </a:documentation>
      <zeroOrMore>
        <ref name="notLost"/> 
      </zeroOrMore>
    </define>

  </div>

</grammar>
]]></artwork>
        </figure>
      </t>
    </section>
    <section anchor="online-examples" title="Examples Online">
      <t> The XML examples and Relax NG schemas may be found <xref target="URL_for_examples"
        >online</xref>. </t>
    </section>

  </back>
</rfc>
