From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc5222.txt | 3867 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 3867 insertions(+)
 create mode 100644 doc/rfc/rfc5222.txt

(limited to 'doc/rfc/rfc5222.txt')

diff --git a/doc/rfc/rfc5222.txt b/doc/rfc/rfc5222.txt
new file mode 100644
index 0000000..2229c6f
--- /dev/null
+++ b/doc/rfc/rfc5222.txt
@@ -0,0 +1,3867 @@
+
+
+
+
+
+
+Network Working Group                                          T. Hardie
+Request for Comments: 5222                                Qualcomm, Inc.
+Category: Standards Track                                      A. Newton
+                                  American Registry for Internet Numbers
+                                                          H. Schulzrinne
+                                                     Columbia University
+                                                           H. Tschofenig
+                                                  Nokia Siemens Networks
+                                                             August 2008
+
+
+            LoST: A Location-to-Service Translation Protocol
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes an XML-based protocol for mapping service
+   identifiers and geodetic or civic location information to service
+   contact URIs.  In particular, it can be used to determine the
+   location-appropriate Public Safety Answering Point (PSAP) for
+   emergency services.
+
+Table of Contents
+
+1.  Introduction .................................................. 3
+2.  Terminology and Requirements Notation ......................... 4
+3.  Overview of Protocol Usage .................................... 5
+4.  LoST Servers and Their Resolution  ............................ 6
+5.  The <mapping> Element  ........................................ 7
+  5.1.  The Mapping Data Source: 'source', 'sourceId', and
+        'lastUpdated' Attributes .................................. 7
+  5.2.  Mapping Validity:  The 'expires' Attribute ................ 8
+  5.3.  Describing the Service with the <displayName> Element  .... 8
+  5.4.  The Mapped Service: The <service> Element ................. 8
+  5.5.  Defining the Service Region with the <serviceBoundary>
+        Element  .................................................. 9
+  5.6.  Service Boundaries by Reference: The
+        <serviceBoundaryReference> Element ........................ 9
+  5.7.  The Service Number: The <serviceNumber> Element  ......... 10
+  5.8.  Service URLs: The <uri> Element  ......................... 10
+
+
+
+
+Hardie, et al.              Standards Track                     [Page 1]
+
+RFC 5222                          LoST                       August 2008
+
+
+6.  Path of a Request: The <path> Element  ....................... 10
+7.  Identifying the Location Element Used for Mapping:
+    <locationUsed> ............................................... 11
+8.  Mapping a Location and Service to URLs: <findService>  ....... 11
+  8.1.  Overview ................................................. 11
+  8.2.  Examples ................................................. 11
+    8.2.1.  Example Using Geodetic Coordinates ................... 11
+    8.2.2.  Civic Address Mapping Example  ....................... 13
+  8.3.  Components of the <findService> Request  ................. 15
+    8.3.1.  The <location> Element ............................... 15
+    8.3.2.  Identifying the Service:  The <service> Element  ..... 16
+    8.3.3.  Recursion and Iteration  ............................. 16
+    8.3.4.  Service Boundary ..................................... 16
+    8.3.5.  Requesting Civic Location Validation ................. 16
+  8.4.  Components of the Mapping Response
+        <findServiceResponse>  ................................... 18
+    8.4.1.  Overview ............................................. 18
+    8.4.2.  Civic Address Validation: The <locationValidation>
+            Element  ............................................. 19
+9.  Retrieving the Service Boundary via <getServiceBoundary> ..... 19
+10. List Services: <listServices>  ............................... 21
+11. List Services By Location: <listServicesByLocation>  ......... 22
+12. Location Profiles  ........................................... 24
+  12.1. Location Profile Usage ................................... 25
+  12.2. Two-Dimensional Geodetic Profile ......................... 30
+  12.3. Basic Civic Profile  ..................................... 31
+13. Errors, Warnings, and Redirects  ............................. 32
+  13.1. Errors ................................................... 32
+  13.2. Warnings ................................................. 34
+  13.3. Redirects  ............................................... 36
+14. LoST Transport: HTTP ......................................... 36
+15. Relax NG Schema  ............................................. 37
+16. Internationalization Considerations  ......................... 44
+17. IANA Considerations  ......................................... 44
+  17.1. U-NAPTR Registrations  ................................... 44
+  17.2. Content-Type Registration for 'application/lost+xml' ..... 44
+  17.3. LoST Relax NG Schema Registration  ....................... 46
+  17.4. LoST Namespace Registration  ............................. 46
+  17.5. LoST Location Profile Registry ........................... 47
+18. Security Considerations  ..................................... 47
+19. Acknowledgments  ............................................. 48
+20. References ................................................... 51
+  20.1. Normative References ..................................... 51
+  20.2. Informative References ................................... 52
+Appendix A.  Non-Normative RELAX NG Schema in XML Syntax ......... 54
+Appendix B.  Examples Online ..................................... 67
+
+
+
+
+
+Hardie, et al.              Standards Track                     [Page 2]
+
+RFC 5222                          LoST                       August 2008
+
+
+1.  Introduction
+
+   Protocols such as Naming Authority Pointer (NAPTR) records and the
+   Service Location Protocol (SLP) can be used to discover servers
+   offering a particular service.  However, for an important class of
+   services the appropriate specific service instance depends both on
+   the identity of the service and the geographic location of the entity
+   that needs to reach it.  Emergency telecommunications services are an
+   important example; here, the service instance is a Public Safety
+   Answering Point (PSAP) that has jurisdiction over the location of the
+   user making the call.  The desired PSAP isn't necessarily the one
+   that is topologically or even line-of-sight closest to the caller;
+   rather, it is the one that serves the caller's location based on
+   jurisdictional boundaries.
+
+   This document describes a protocol for mapping a service identifier
+   and location information compatible with the Presence Information
+   Data Format Location Object (PIDF-LO) [6] to one or more service
+   URIs.  Service identifiers take the form of the service URNs
+   described in [9].  Location information here includes revised civic
+   location information [10] and a subset of the PIDF-LO profile [13],
+   which consequently includes the Geo-Shapes [12] defined for GML [11].
+   Example service URI schemes include sip [14], xmpp [15], and tel
+   [16].  While the initial focus is on providing mapping functions for
+   emergency services, it is likely that the protocol is applicable to
+   other service URNs.  For example, in the United States, the "2-1-1"
+   and "3-1-1" service numbers follow a similar location-to-service
+   behavior as emergency services.
+
+   This document names this protocol "LoST", for Location-to-Service
+   Translation.  LoST satisfies the requirements [18] for mapping
+   protocols.  LoST provides a number of operations, centered around
+   mapping locations and service URNs to service URLs and associated
+   information.  LoST mapping queries can contain either civic or
+   geodetic location information.  For civic addresses, LoST can
+   indicate which parts of the civic address are known to be valid or
+   invalid, thus providing address validation, as described in Section
+   3.5 of [18].  LoST indicates errors in the location data to
+   facilitate debugging and proper user feedback, but also provides
+   best-effort answers.
+
+   LoST queries can be resolved recursively or iteratively.  To minimize
+   round trips and to provide robustness against network failures, LoST
+   supports caching of individual mappings and indicates the region for
+   which the same answer would be returned ("service region").
+
+
+
+
+
+
+Hardie, et al.              Standards Track                     [Page 3]
+
+RFC 5222                          LoST                       August 2008
+
+
+   As defined in this document, LoST messages are carried in HTTP and
+   HTTPS protocol exchanges, facilitating use of TLS for protecting the
+   integrity and confidentiality of requests and responses.
+
+   This document focuses on the description of the protocol between the
+   mapping client and the mapping server.  Other functions, such as
+   discovery of mapping servers, data replication and the overall
+   mapping server architecture are described in a separate document
+   [19].
+
+   The query message carries location information and a service
+   identifier encoded as a Uniform Resource Name (URN) (see [9]) from
+   the LoST client to the LoST server.  The LoST server uses its
+   database to map the input values to one or more Uniform Resource
+   Identifiers (URIs) and returns those URIs along with optional
+   information, such as hints about the service boundary, in a response
+   message to the LoST client.  If the server cannot resolve the query
+   itself, it may in turn query another server or return the address of
+   another LoST server, identified by a LoST server name.  In addition
+   to the mapping function described in Section 8, the protocol also
+   allows to retrieve the service boundary (see Section 9) and to list
+   the services available for a particular location (see Section 11) or
+   supported by a particular server (see Section 10).
+
+2.  Terminology and Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [1].
+
+   This document uses the following terms:
+
+   Mapping:
+      Mapping is a process that takes a location and a service
+      identifier as inputs and returns one or more URIs.  Those URIs can
+      point either to a host providing that service or to a host that in
+      turn routes the request to the final destination.  This definition
+      is a generalization of the term "mapping" as used in [18], because
+      LoST can be used for non-emergency services.
+
+   LoST client:
+      A host acts as a LoST client if it sends LoST query messages and
+      receives LoST response messages.
+
+   LoST server:
+      A host acts as a LoST server if it receives LoST query messages
+      and sends LoST response messages.  In recursive operation, the
+      same entity may be both a client and a server.
+
+
+
+Hardie, et al.              Standards Track                     [Page 4]
+
+RFC 5222                          LoST                       August 2008
+
+
+   Authoritative LoST server:
+      An authoritative server acts only as a server and successfully
+      resolves the input location and service identifier to a URI or set
+      of URIs.
+
+   Service boundary:
+      A service boundary circumscribes the region within which all
+      locations map to the same service URI or set of URIs for a given
+      service.  A service boundary may consist of several non-contiguous
+      geometric shapes.
+
+   Validation:
+      The term "validation" describes the behavior defined as "location
+      validation" in Section 3.5 of [18].
+
+   Additional emergency service terminology can be found in [18].
+
+3.  Overview of Protocol Usage
+
+   The LoST protocol supports the following types of queries and
+   responses:
+
+   <findService> and <findServiceResponse>
+      A LoST client retrieves contact URIs based on location information
+      and a service identifier with this request and response.  The same
+      query type may also ask for location validation and for service
+      numbers, either combined with a mapping request or separately.
+      The details can be found in Section 8.
+
+   <getServiceBoundary> and <getServiceBoundaryResponse>
+      A LoST client obtains a service boundary with this request and
+      response, as described in Section 9.
+
+   <listServices> and <listServicesResponse>
+      With this request and response, a LoST client can find out which
+      services a LoST server supports, as described in Section 10.
+
+   <listServicesByLocation> and <listServicesByLocationResponse>
+      A LoST client can determine with this request and response which
+      services are available for a specific location region.  Section 11
+      describes the details.
+
+   LoST clients may initiate any of the above queries at any time.
+   Among the common triggers are:
+
+   1.  when the client initially starts up or attaches to a network;
+
+
+
+
+
+Hardie, et al.              Standards Track                     [Page 5]
+
+RFC 5222                          LoST                       August 2008
+
+
+   2.  when the client detects that its location has changed
+       sufficiently that it is outside the bounds of the service region;
+
+   3.  when a SIP message arrives at a SIP proxy performing location-
+       based call routing;
+
+   4.  when cached mapping information has expired; and
+
+   5.  when invoking a particular service.  At that time, a client may
+       omit requests for service boundaries or other auxiliary
+       information.
+
+   A service-specific Best Current Practice (BCP) document, such as
+   [21], governs whether a client is expected to invoke the mapping
+   service just before needing the service or whether to rely on cached
+   answers.  Cache entries expire at their expiration time (see
+   Section 5.2), or they become invalid if the caller's device moves
+   beyond the boundaries of the service region.  Service-specific Best
+   Current Practice documents may also provide guidance on the contact
+   URI schemes most appropriate to the service.  As a general set of
+   guidelines, URI schemes that do not provide mechanisms for actually
+   initiating a contact method should be avoided (examples include data,
+   info, cid, and tag) as transforming those references into contact
+   mechanisms requires a layer of indirection that makes the overall
+   mechanism more fragile.  Provisionally registered URI schemes should
+   also be carefully considered before use, because they are subject to
+   change in core semantics.
+
+4.  LoST Servers and Their Resolution
+
+   LoST servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/
+   Dynamic Delegation Discovery Service) [8] application unique strings,
+   in the form of a DNS name.  An example is 'lostserver.example.com'.
+
+   Clients need to use the U-NAPTR [8] specification described below to
+   obtain a URI (indicating host and protocol) for the applicable LoST
+   service.  In this document, only the HTTP and HTTPS URL schemes are
+   defined.  Note that the HTTP URL can be any valid HTTP URL, including
+   those containing path elements.
+
+   The following two DNS entries show the U-NAPTR resolution for
+   "example.com" to the HTTPS URL https://lostserv.example.com/secure or
+   the HTTP URL http://lostserver.example.com, with the former being
+   preferred.
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                     [Page 6]
+
+RFC 5222                          LoST                       August 2008
+
+
+       example.com.
+
+       IN NAPTR 100  10   "u"    "LoST:https"
+            "!.*!https://lostserver.example.com/secure!"  ""
+
+       IN NAPTR 200  10   "u"    "LoST:http"
+            "!.*!http://lostserver.example.com!"  ""
+
+   Clients learn the LoST server's host name by means beyond the scope
+   of this specification, such as SIP configuration and DHCP [25].
+
+5.  The <mapping> Element
+
+   The <mapping> element is the core data element in LoST, describing a
+   service region and the associated service URLs.  Its attributes and
+   elements are described in subsections below.
+
+5.1.  The Mapping Data Source: 'source', 'sourceId', and 'lastUpdated'
+      Attributes
+
+   The 'source', 'sourceId', and 'lastUpdated' attributes uniquely
+   identify a particular mapping record.  They are created by the
+   authoritative source for a mapping and are never modified when a
+   mapping is served from a cache.  All three attributes are REQUIRED
+   for all <mapping> elements.  A receiver can replace a mapping with
+   another one having the same 'source' and 'sourceId' and a more recent
+   time in 'lastUpdated'.
+
+   The 'source' attribute contains a LoST application unique string
+   identifying the authoritative generator of the mapping (Section 4).
+
+   The 'sourceId' attribute identifies a particular mapping and contains
+   an opaque token that MUST be unique among all different mappings
+   maintained by the authoritative source for that particular service.
+   For example, a Universally Unique Identifier (UUID) is a suitable
+   format.
+
+   The 'lastUpdated' attribute describes when a specific instance of
+   mapping, identified by the combination of 'source' and 'sourceId',
+   was last changed.  The contents of this attribute has the XML data
+   type dateTime in its timezoned form, using the canonical UTC
+   representation with the letter 'Z' as the timezone indicator.
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                     [Page 7]
+
+RFC 5222                          LoST                       August 2008
+
+
+5.2.  Mapping Validity:  The 'expires' Attribute
+
+   The 'expires' attribute contains the absolute time at which the
+   mapping becomes invalid.  The contents of this attribute is a
+   timezoned XML type dateTime, in canonical representation.  The
+   <mapping> element MUST include the 'expires' attribute.
+
+   Optionally, this attribute may contain the values of 'NO-CACHE' and
+   'NO-EXPIRATION' instead of a dateTime value.  The value 'NO-CACHE' is
+   an indication that the mapping should not be cached.  The value of
+   'NO-EXPIRATION' is an indication that the mapping does not expire.
+
+   On occasion, a server may be forced to return an expired mapping if
+   it cannot reach the authoritative server or the server fails to
+   return a usable answer.  Clients and servers MAY cache the mapping so
+   that they have at least some information available.  Caching servers
+   that have such stale information SHOULD re-attempt the query each
+   time a client requests a mapping.  Since the expired mapping will be
+   returned to the client as a non-error/non-warning response, the
+   client MUST check the 'expires' attribute; if the mapping has
+   expired, local policy at the client determines whether it discards
+   the answer and tries again later or uses the possibly stale response.
+
+5.3.  Describing the Service with the <displayName> Element
+
+   Zero or more <displayName> elements describe the service with a
+   string that is suitable for display to human users, each annotated
+   with the 'xml:lang' attribute that contains a language tag to aid in
+   the rendering of text.
+
+5.4.  The Mapped Service: The <service> Element
+
+   The mandatory <service> element identifies the service for which this
+   mapping applies.  Two cases need to be distinguished when the LoST
+   server sets the <service> element in the response message:
+
+   1.  If the requested service, identified by the service URN [9] in
+       the <service> element of the request, exists for the location
+       indicated, then the LoST server copies the service URN from the
+       request into the <service> element.
+
+   2.  If, however, the requested service, identified by the service URN
+       [9] in the <service> element in the request, does not exist for
+       the location indicated, the server either can return a
+       <serviceNotImplemented> (Section 13.1) error or can provide an
+       alternate service that approximates the desired service for that
+
+
+
+
+
+Hardie, et al.              Standards Track                     [Page 8]
+
+RFC 5222                          LoST                       August 2008
+
+
+       location.  In the latter case, the server MUST include a
+       <service> element with the alternative service URN.  The choice
+       of service URN is left to local policy, but the alternate service
+       should be able to satisfy the original service request.
+
+5.5.  Defining the Service Region with the <serviceBoundary> Element
+
+   A response MAY indicate the region for which the service URL returned
+   would be the same as in the actual query, the so-called service
+   region.  The service region can be indicated by value or by reference
+   (see Section 5.6).  If a client moves outside the service area and
+   wishes to obtain current service data, it sends a new query with its
+   current location.  The service region is described by value in one or
+   more <serviceBoundary> elements, each formatted according to a
+   specific location profile, identified by the 'profile' attribute (see
+   Section 12). <serviceBoundary> elements formatted according to
+   different location profiles are alternative representations of the
+   same area, not additive to one another; this allows a client
+   understanding only one of the profile types to be sure it has a
+   complete view of the serviceBoundary.  Within a serviceBoundary
+   element there may, however, be multiple locations which are additive;
+   this is necessary because some <serviceBoundary> areas could not be
+   easily expressed with a single shape or civic location.  If included
+   in a response, the <serviceBoundary> element MUST contain at least
+   one service boundary that uses the same profile as the request.
+
+   A service boundary is requested by the client, using the
+   'serviceBoundary' attribute in the request with the value set to
+   "value".
+
+5.6.  Service Boundaries by Reference: The <serviceBoundaryReference>
+      Element
+
+   Since geodetic service boundaries may contain thousands of points and
+   can thus be quite large, clients may wish to conserve bandwidth by
+   requesting a reference to the service boundary instead of the value
+   described in Section 5.5.  The identifier of the service boundary is
+   returned as an attribute of the <serviceBoundaryReference> element,
+   along with a LoST application unique string (see Section 4)
+   identifying the server from where it can be retrieved.  The actual
+   value of the service boundary is then retrieved with the
+   getServiceBoundary (Section 9) request.
+
+   A reference to a service boundary is requested by the client using
+   the 'serviceBoundary' attribute in the request with the value set to
+   "reference".  A LoST server may decide, based on local policy, to
+   return the service boundary by value or to omit the
+   <serviceBoundaryReference> element in the response.
+
+
+
+Hardie, et al.              Standards Track                     [Page 9]
+
+RFC 5222                          LoST                       August 2008
+
+
+   The identifier is a random token with at least 128 bits of entropy
+   and can be assumed to be globally unique.  It uniquely references a
+   particular boundary.  If the boundary changes, a new identifier MUST
+   be chosen.  Because of these properties, a client receiving a mapping
+   response can simply check if it already has a copy of the boundary
+   with that identifier.  If so, it can skip checking with the server
+   whether the boundary has been updated.  Since service boundaries are
+   likely to remain unchanged for extended periods of time, possibly
+   exceeding the normal lifetime of the service URL, this approach
+   avoids unnecessarily refreshing the boundary information just because
+   the remainder of the mapping has become invalid.
+
+5.7.  The Service Number: The <serviceNumber> Element
+
+   The service number is returned in the optional <serviceNumber>
+   element.  It contains a string of digits, * and # that a user on a
+   device with a 12-key dial pad could use to reach that particular
+   service.
+
+5.8.  Service URLs: The <uri> Element
+
+   The response returns the service URLs in one or more <uri> elements.
+   The URLs MUST be absolute URLs.  The ordering of the URLs has no
+   particular significance.  Each URL scheme MUST only appear at most
+   once, but it is permissible to include both secured and regular
+   versions of a protocol, such as both 'http' and 'https' or 'sip' and
+   'sips'.
+
+6.  Path of a Request: The <path> Element
+
+   To prevent loops and to allow tracing of request and response paths,
+   all requests that allow recursion include a <path> element that
+   contains one or more <via> elements, each possessing an attribute
+   containing a LoST application unique string (see Section 4).  The
+   order of <via> elements corresponds to the order of LoST servers,
+   i.e., the first <via> element identifies the server that initially
+   received the request from the client issuing the request.  Every
+   server in a recursive query operation is included in the <path>
+   element, including the first server to receive it.
+
+   The server that answers the request instead of forwarding it, such as
+   the authoritative server, copies the <path> element verbatim into the
+   response.  The <path> element is not modified in responses as the
+   responses traverses the server chain back to the querying client.
+
+   If a query is answered iteratively, the querier includes all servers
+   that it has already contacted.
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 10]
+
+RFC 5222                          LoST                       August 2008
+
+
+   When a cached mapping is returned, then the <path> element cached
+   together with the mapping is returned.
+
+   The example in Figure 4 indicates that the answer was given to the
+   client by the LoST server at esgw.ueber-110.de.example, which got the
+   answer from the (authoritative) LoST server at
+   polizei.muenchen.de.example.
+
+7.  Identifying the Location Element Used for Mapping: <locationUsed>
+
+   Several of the requests can provide one or more <location> elements,
+   among which the server gets to choose.  It is useful for the client
+   to be able to determine which one was actually used in producing the
+   result.  For that purpose, the <location> tag MUST contain an 'id'
+   attribute that uniquely identifies the <location> element.  The
+   format of the identifier is left to the client; it could, for
+   example, use a hash of the location information.  The server returns
+   the identifier for the <location> element it used in the
+   <locationUsed> tag.
+
+8.  Mapping a Location and Service to URLs: <findService>
+
+8.1.  Overview
+
+   The <findService> query constitutes the core of the LoST
+   functionality, mapping civic or geodetic locations to URLs and
+   associated data.  After giving an example, we enumerate the elements
+   of the query and response.
+
+8.2.  Examples
+
+8.2.1.  Example Using Geodetic Coordinates
+
+   The following is an example of mapping a service to a location using
+   geodetic coordinates, for the service associated with the police
+   (urn:service:sos.police).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 11]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <findService
+     xmlns="urn:ietf:params:xml:ns:lost1"
+     xmlns:p2="http://www.opengis.net/gml"
+     serviceBoundary="value"
+     recursive="true">
+
+     <location id="6020688f1ce1896d" profile="geodetic-2d">
+       <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
+          <p2:pos>37.775 -122.422</p2:pos>
+       </p2:Point>
+     </location>
+     <service>urn:service:sos.police</service>
+
+   </findService>
+
+                 Figure 1: A <findService> geodetic query
+
+   Given the query above, a server would respond with a service, and
+   information related to that service.  In the example below, the
+   server has mapped the location given by the client for a police
+   service to the New York City Police Department, instructing the
+   client that it may contact them via the URIs "sip:nypd@example.com"
+   and "xmpp:nypd@example.com".  The server has also given the client a
+   geodetic, two-dimensional boundary for this service.  The mapping was
+   last updated on November 1, 2006 and expires on January 1, 2007.  If
+   the client's location changes beyond the given service boundary or
+   the expiration time has been reached, it may want to requery for this
+   information, depending on the usage environment of LoST.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 12]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
+     xmlns:p2="http://www.opengis.net/gml">
+     <mapping
+       expires="2007-01-01T01:44:33Z"
+       lastUpdated="2006-11-01T01:00:00Z"
+       source="authoritative.example"
+       sourceId="7e3f40b098c711dbb6060800200c9a66">
+       <displayName xml:lang="en">
+         New York City Police Department
+       </displayName>
+       <service>urn:service:sos.police</service>
+       <serviceBoundary profile="geodetic-2d">
+         <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
+           <p2:exterior>
+             <p2:LinearRing>
+               <p2:pos>37.775 -122.4194</p2:pos>
+               <p2:pos>37.555 -122.4194</p2:pos>
+               <p2:pos>37.555 -122.4264</p2:pos>
+               <p2:pos>37.775 -122.4264</p2:pos>
+               <p2:pos>37.775 -122.4194</p2:pos>
+             </p2:LinearRing>
+           </p2:exterior>
+         </p2:Polygon>
+       </serviceBoundary>
+       <uri>sip:nypd@example.com</uri>
+       <uri>xmpp:nypd@example.com</uri>
+       <serviceNumber>911</serviceNumber>
+     </mapping>
+     <path>
+       <via source="resolver.example"/>
+       <via source="authoritative.example"/>
+     </path>
+     <locationUsed id="6020688f1ce1896d"/>
+   </findServiceResponse>
+
+             Figure 2: A <findServiceResponse> geodetic answer
+
+8.2.2.  Civic Address Mapping Example
+
+   The example below shows how to map a service to a location much like
+   the example in Section 8.2.1, but using civic address location
+   information.  In this example, the client requests the service
+   associated with police (urn:service:sos.police) along with a specific
+   civic address (house number 6 on a street named Otto-Hahn-Ring in
+   Munich, Germany).
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 13]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <findService xmlns="urn:ietf:params:xml:ns:lost1"
+     recursive="true" serviceBoundary="value">
+     <location id="627b8bf819d0bad4d" profile="civic">
+       <civicAddress
+         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
+         <country>DE</country>
+         <A1>Bavaria</A1>
+         <A3>Munich</A3>
+         <A6>Otto-Hahn-Ring</A6>
+         <HNO>6</HNO>
+         <PC>81675</PC>
+       </civicAddress>
+     </location>
+     <service>urn:service:sos.police</service>
+   </findService>
+
+               Figure 3: A <findService> civic address query
+
+   Given the query above, a server would respond with a service, and
+   information related to that service.  In the example below, the
+   server has mapped the location given by the client for a police
+   service to the Muenchen Polizei-Abteilung, instructing the client
+   that it may contact them via the URIs sip:munich-police@example.com
+   and xmpp:munich-police@example.com.  The server has also given the
+   client a civic address boundary (the city of Munich) for this
+   service.  The mapping was last updated on November 1, 2006 by the
+   authoritative source "polizei.muenchen.de.example" and expires on
+   January 1, 2007.  This instructs the client to requery for the
+   information if its location changes beyond the given service boundary
+   (i.e., beyond the indicated district of Munich) or after January 1,
+   2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 14]
+
+RFC 5222                          LoST                       August 2008
+
+
+    <?xml version="1.0" encoding="UTF-8"?>
+    <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
+      <mapping
+        expires="2007-01-01T01:44:33Z"
+        lastUpdated="2006-11-01T01:00:00Z"
+        source="esgw.ueber-110.de.example"
+        sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
+        <displayName xml:lang="de">
+          Muenchen Polizei-Abteilung
+        </displayName>
+        <service>urn:service:sos.police</service>
+        <serviceBoundary
+          profile="civic">
+          <civicAddress
+            xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
+            <country>DE</country>
+            <A1>Bavaria</A1>
+            <A3>Munich</A3>
+            <PC>81675</PC>
+          </civicAddress>
+        </serviceBoundary>
+        <uri>sip:munich-police@example.com</uri>
+        <uri>xmpp:munich-police@example.com</uri>
+        <serviceNumber>110</serviceNumber>
+      </mapping>
+      <path>
+        <via source="esgw.ueber-110.de.example"/>
+        <via source="polizei.muenchen.de.example"/>
+      </path>
+      <locationUsed id="627b8bf819d0bad4d"/>
+    </findServiceResponse>
+
+          Figure 4: A <findServiceResponse> civic address answer
+
+8.3.  Components of the <findService> Request
+
+   The <findService> request includes attributes and elements that
+   govern whether the request is handled iteratively or recursively,
+   whether location validation is performed, and which elements may be
+   contained in the response.
+
+8.3.1.  The <location> Element
+
+   The <findService> query communicates location information using one
+   or more <location> elements, which MUST conform to a location profile
+   (see Section 12).  There MUST NOT be more than one location element
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 15]
+
+RFC 5222                          LoST                       August 2008
+
+
+   for each distinct location profile.  The order of location elements
+   is significant; the server uses the first location element where it
+   understands the location profile.
+
+8.3.2.  Identifying the Service:  The <service> Element
+
+   The type of service desired is specified by the <service> element.
+   It contains service URNs from the registry established in [9].
+
+8.3.3.  Recursion and Iteration
+
+   LoST can operate in either recursive or iterative mode, on a request-
+   by-request basis.  In recursive mode, the LoST server initiates
+   queries on behalf of the requester and returns the result to the
+   requester.
+
+   In iterative mode, the server contacted returns a redirection
+   response indicating the next server to be queried if the server
+   contacted cannot provide an answer itself.
+
+   For the queries defined in this document, only the LoST <findService>
+   and <listServicesByLocation> queries can be recursive, as indicated
+   by the 'recursive' attribute.  A value of "true" indicates a
+   recursive query, with the default being "false" when the attribute is
+   omitted.  Regardless of the attribute, a server MAY always answer a
+   query by providing a LoST application unique string (see Section 4),
+   i.e., indirection; however, it MUST NOT recurse if the attribute is
+   "false".
+
+8.3.4.  Service Boundary
+
+   LoST <mapping> elements can describe the service boundary either by
+   value or by reference.  Returning a service boundary reference is
+   generally more space-efficient for geospatial (polygon) boundaries
+   and if the boundaries change rarely, but does incur an additional
+   <getServiceBoundary> request.  The querier can express a preference
+   for one or the other modality with the 'serviceBoundary' attribute in
+   the <findService> request, but the server makes the final decision as
+   to whether to return a reference or a value.
+
+8.3.5.  Requesting Civic Location Validation
+
+   Civic address validation is requested by setting the optional
+   attribute 'validateLocation' to true.  If the attribute is omitted,
+   it is assumed to be false.  The response is described in
+   Section 8.4.2.  The example in Figure 5 demonstrates address
+   validation.  If the server chooses a geodetic location among the
+   locations provided in a request, the attribute is ignored.
+
+
+
+Hardie, et al.              Standards Track                    [Page 16]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <findService
+     xmlns="urn:ietf:params:xml:ns:lost1"
+     recursive="true"
+     validateLocation="true"
+     serviceBoundary="value">
+     <location id="627b8bf819d0bad4d" profile="civic">
+       <civicAddress
+         xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
+         <country>DE</country>
+         <A1>Bavaria</A1>
+         <A3>Munich</A3>
+         <A6>Otto-Hahn-Ring</A6>
+         <HNO>6</HNO>
+         <PC>81675</PC>
+       </civicAddress>
+     </location>
+     <service>urn:service:sos.police</service>
+   </findService>
+
+      Figure 5: A <findService> query with address validation request
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 17]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
+     <mapping
+       expires="2007-01-01T01:44:33Z"
+       lastUpdated="2006-11-01T01:00:00Z"
+       source="authoritative.example"
+       sourceId="4db898df52b84edfa9b6445ea8a0328e">
+       <displayName xml:lang="de">
+         Muenchen Polizei-Abteilung
+       </displayName>
+       <service>urn:service:sos.police</service>
+       <serviceBoundary profile="civic">
+         <civicAddress
+           xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
+           <country>DE</country>
+           <A1>Bavaria</A1>
+           <A3>Munich</A3>
+           <PC>81675</PC>
+         </civicAddress>
+       </serviceBoundary>
+       <uri>sip:munich-police@example.com</uri>
+       <uri>xmpp:munich-police@example.com</uri>
+       <serviceNumber>110</serviceNumber>
+     </mapping>
+     <locationValidation>
+       <valid>country A1 A3 A6</valid>
+       <invalid>PC</invalid>
+       <unchecked>HNO</unchecked>
+     </locationValidation>
+     <path>
+       <via source="resolver.example"/>
+       <via source="authoritative.example"/>
+     </path>
+     <locationUsed id="627b8bf819d0bad4d"/>
+   </findServiceResponse>
+
+     Figure 6: A <findServiceResponse> message with address validation
+                                information
+
+8.4.  Components of the Mapping Response <findServiceResponse>
+
+8.4.1.  Overview
+
+   Mapping responses consist of the <mapping> element (Section 5)
+   describing the mapping itself, possibly followed by warnings
+   (Section 13.2), location validation information (Section 8.4.2), and
+   an indication of the path (Section 6) the response has taken.
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 18]
+
+RFC 5222                          LoST                       August 2008
+
+
+8.4.2.  Civic Address Validation: The <locationValidation> Element
+
+   A server can indicate in its response which civic address elements it
+   has recognized as valid, which ones it has ignored, and which ones it
+   has checked and found to be invalid.  The server SHOULD include this
+   information if the 'validateLocation' attribute in the request was
+   true, but local policy at the server may allow this information to be
+   omitted.  Each element contains a list of tokens separated by
+   whitespace, enumerating the civic location labels used in child
+   elements of the <civicAddress> element.  The <valid> element
+   enumerates those civic address elements that have been recognized as
+   valid by the LoST server and that have been used to determine the
+   mapping.  The <unchecked> elements enumerates the civic address
+   elements that the server did not check and that were not used in
+   determining the response.  The <invalid> element enumerate civic
+   address elements that the server attempted to check, but that did not
+   match the other civic address elements found in the <valid> list.
+   Civic location tokens that are not listed in either the <valid>,
+   <invalid>, or <unchecked> element belong to the class of unchecked
+   tokens.
+
+   Note that the same address can yield different responses if parts of
+   the civic address contradict each other.  For example, if the postal
+   code does not match the city, local server policy determines whether
+   the postal code or the city is considered valid.  The mapping
+   naturally corresponds to the valid elements.
+
+   The example shown in Figure 5 and in Figure 6 indicates that the
+   tokens 'country', 'A1', 'A3', and 'A6' have been validated by the
+   LoST server.  The server considered the postal code 81675 in the <PC>
+   element as not valid for this location.  The 'HNO' token belongs to
+   the class of unchecked location tokens.
+
+9.  Retrieving the Service Boundary via <getServiceBoundary>
+
+   As discussed in Section 5.5, the <findServiceResponse> can return a
+   globally unique identifier in the 'serviceBoundary' attribute that
+   can be used to retrieve the service boundary, rather than returning
+   the boundary by value.  This is shown in the example in Figure 7 and
+   Figure 8.  The client can then retrieve the boundary using the
+   <getServiceBoundary> request and obtains the boundary in the
+   <getServiceBoundaryResponse>, illustrated in the example in Figure 9
+   and Figure 10.  The client issues the request to the server
+   identified in the 'server' attribute of the
+   <serviceBoundaryReference> element.  These requests are always
+   directed to the authoritative server and do not recurse.
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 19]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?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>
+
+    Figure 7: <findService> request and response with service boundary
+                                 reference
+
+   <?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>
+
+       Figure 8: <findServiceResponse> message with service boundary
+                                 reference
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 20]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
+       key="7214148E0433AFE2FA2D48003D31172E"/>
+
+     Figure 9: Requesting a service boundary with <getServiceBoundary>
+
+    <?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>
+
+               Figure 10: Geodetic service boundary response
+
+10.  List Services: <listServices>
+
+   A LoST client can ask a LoST server for the list of services that it
+   understands, primarily for diagnostic purposes.  The query does not
+   contain location information, as it simply provides an indication of
+   which services the server can look up, not whether a particular
+   service is offered for a particular area.  Typically, only top-level
+   services are included in the answer, implying support for all sub-
+   services.  Since the query is answered by the queried server, there
+   is no notion of recursion or indirection.  The
+   <listServicesByLocation> (Section 11) query below can be used to find
+   out whether a particular service is offered for a specific location.
+   An example request and response are shown in Figure 11.
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 21]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <listServices
+     xmlns="urn:ietf:params:xml:ns:lost1">
+     <service>urn:service:sos</service>
+   </listServices>
+
+                Figure 11: Example of <ListServices> query
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <listServicesResponse
+    xmlns="urn:ietf:params:xml:ns:lost1">
+    <serviceList>
+     urn:service:sos.ambulance
+     urn:service:sos.animal-control
+     urn:service:sos.fire
+     urn:service:sos.gas
+     urn:service:sos.mountain
+     urn:service:sos.marine
+     urn:service:sos.physician
+     urn:service:sos.poison
+     urn:service:sos.police
+    </serviceList>
+    <path>
+     <via source="authoritative.example"/>
+    </path>
+   </listServicesResponse>
+
+               Figure 12: Example of <ListServicesResponse>
+
+11.  List Services By Location: <listServicesByLocation>
+
+   A LoST client can ask a LoST server for the list of services it knows
+   about for a particular area.  The <listServicesByLocation> query
+   contains one or more <location> elements, each from a different
+   location profile (Section 12), and may contain the <service> element.
+   As for <findService>, the server selects the first location element
+   that has a profile the server understands and it can operate either
+   recursively or iteratively; <via> elements track the progress of the
+   request.  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.
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 22]
+
+RFC 5222                          LoST                       August 2008
+
+
+   If the query contains the <service> element, the LoST server returns
+   only immediate child services of the queried service that are
+   available for the provided location.  If the <service> element is
+   absent, the LoST service returns all top-level services available for
+   the provided location that it knows about.
+
+   A server responds to this query with a
+   <listServicesByLocationResponse> response.  This response MAY contain
+   <via> elements (see Section 6) and MUST contain a <serviceList>
+   element, consisting of a whitespace-separated list of service URNs.
+   The query and response are illustrated in Figure 13 and in Figure 14,
+   respectively.
+
+   <?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>
+
+           Figure 13: Example of <ListServicesbyLocation> query
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 23]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?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>
+
+      Figure 14: Example of <ListServicesByLocationResponse> response
+
+12.  Location Profiles
+
+   LoST uses location information in <location> elements in requests and
+   <serviceBoundary> elements in responses.  Such location information
+   may be expressed in a variety of ways.  This variety can cause
+   interoperability problems where a request or response contains
+   location information in a format not understood by the server or the
+   client, respectively.  To achieve interoperability, 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:
+
+   geodetic-2d:
+      a profile for two-dimensional geodetic location information, as
+      described in Section 12.2;.
+
+   civic:
+      a profile consisting of civic address location information, as
+      described in Section 12.3.
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 24]
+
+RFC 5222                          LoST                       August 2008
+
+
+   Requests and responses containing <location> or <serviceBoundary>
+   elements MUST contain location information in exactly one of the two
+   baseline profiles, in addition to zero or more additional profiles.
+   The ordering of location information indicates a preference on the
+   part of the sender.
+
+   Standards action is required for defining new profiles.  A location
+   profile MUST define:
+
+   1.  The token identifying it in the LoST location profile registry.
+
+   2.  The formal definition of the XML to be used in requests, i.e., an
+       enumeration and definition of the XML child elements of the
+       <location> element.
+
+   3.  The formal definition of the XML to be used in responses, i.e.,
+       an enumeration and definition of the XML child elements of the
+       <serviceBoundary> element.
+
+   4.  The declaration of whether geodetic-2d or civic is to be used as
+       the baseline profile.  It is necessary to explicitly declare the
+       baseline profile as future profiles may be combinations of
+       geodetic and civic location information.
+
+12.1.  Location Profile Usage
+
+   A location profile is identified by a token in an IANA-maintained
+   registry (Section 17.5).  Clients send location information compliant
+   with a location profile, and servers respond with location
+   information compliant with that same location profile.
+
+   When a LoST client sends a <findService> request that provides
+   location information, it includes one or more <location> elements.  A
+   <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 "locationProfileUnrecognized" error if it is unable to do
+   so.
+
+   The concept of location profiles is described in Section 12.  With
+   the ability to specify more than one <location> element, the client
+   is able to convey location information for multiple location profiles
+   in the same request.
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 25]
+
+RFC 5222                          LoST                       August 2008
+
+
+   When a LoST server sends a response that contains location
+   information, it uses the <serviceBoundary> elements much like the
+   client uses the <location> elements.  Each <serviceBoundary> 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 <location>
+   elements, subject to the restrictions below.
+
+   Using the location profiles defined in this document, the following
+   rules ensure interoperability between clients and servers:
+
+   1.  A client MUST be capable of understanding the response for the
+       baseline profiles it used in the request.
+
+   2.  If a client sends location information conformant to any location
+       profile other than 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.
+
+   3.  A client MUST NOT send multiple <location> 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.
+
+   4.  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.
+
+   5.  There can only be one instance of each location profile in a
+       query.
+
+   6.  Servers MUST implement all profiles described in this document.
+
+   7.  A server uses the first-listed location profile that it
+       understands and ignores the others.
+
+   8.  If a server receives a request that only contains location
+       information using profiles it does not understand, the server
+       responds with a <locationProfileError> (Section 13.1).
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 26]
+
+RFC 5222                          LoST                       August 2008
+
+
+   9.  The <serviceBoundary> element MUST use the same location profile
+       that was used to retrieve the answer and indicates which profile
+       has been used with the 'profile' attribute.
+
+   These rules enable the use of location profiles not yet specified,
+   while ensuring baseline interoperability.  Take, for example, this
+   scenario 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 27]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?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>
+
+    Figure 15: Example of a <findServices> query with baseline profile
+                             interoperability
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 28]
+
+RFC 5222                          LoST                       August 2008
+
+
+   <?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>
+
+    Figure 16: Example of a <findServiceResponse> message with baseline
+                         profile interoperability
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 29]
+
+RFC 5222                          LoST                       August 2008
+
+
+12.2.  Two-Dimensional Geodetic Profile
+
+   The "geodetic-2d" location profile is identified by the token
+   "geodetic-2d".  Clients and servers use this profile by placing the
+   following location shapes into the <serviceBoundary> or into the
+   <location> element (unless indicated otherwise):
+
+   Point:
+      The <Point> element is described in Section 5.2.1 of [13].
+      Section 5.2.1 of [13] shows also the specification of a <Point>
+      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 <Point> element is not
+      placed into a <serviceBoundary> element.
+
+   Polygon:
+      The <Polygon> element is described in Section 5.2.2 of [13].  The
+      restriction to 16 points for a polygon contained in Section 7.2.2
+      of [12] is not applicable to this document.
+
+   Circle:
+      The <Circle> element is described in Section 5.2.3 of [13].
+
+   Ellipse:
+      The <Ellipse> element is described in Section 5.2.4 of [13].
+
+   ArcBand:
+      The <ArcBand> element is described in Section 5.2.5 of [13].
+
+   When a client uses a <Polygon>, <Circle>, <Ellipse>, or <ArcBand>
+   element within the <location> 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 <mapping> elements if the
+   shape extends across multiple service areas.  Servers are not
+   required to return all possible <mapping> 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).
+
+   In the case where the server does not return multiple <mapping>
+   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
+
+
+
+Hardie, et al.              Standards Track                    [Page 30]
+
+RFC 5222                          LoST                       August 2008
+
+
+   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.
+
+   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.
+
+   When geodetic location information of this location profile is placed
+   in the <serviceBoundary> element, then the elements with geospatial
+   coordinates are alternative descriptions of the same service region,
+   not additive geometries.
+
+12.3.  Basic Civic Profile
+
+   The basic civic location profile is identified by the token 'civic'.
+   Clients use this profile by placing a <civicAddress> element, defined
+   in [10], within the <location> element.
+
+   Servers use this profile by placing a <civicAddress> element, defined
+   in [10], within the <serviceBoundary> element.
+
+   A response MAY contain more than one <serviceBoundary> element with
+   profile 'civic'.  Each <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
+   <serviceBoundary> elements.  Hence, a response may contain multiple
+   <serviceBoundary> elements with civic and/or geodetic location
+   profiles.
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 31]
+
+RFC 5222                          LoST                       August 2008
+
+
+13.  Errors, Warnings, and Redirects
+
+   When a LoST server cannot fulfill a request completely, it can return
+   either an error or a warning, depending on the severity of the
+   problem.  It returns an <errors> element if no useful response can be
+   returned for the query.  It returns a <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.
+
+13.1.  Errors
+
+   LoST defines a pattern for errors, defined as <errors> 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 <errors> element.
+
+   The following errors follow this basic pattern:
+
+   badRequest
+      The server could not parse or otherwise understand a request,
+      e.g., because the XML was malformed.
+
+   forbidden
+      The server refused to send an answer.  This generally only occurs
+      for recursive queries, namely, if the client tried to contact the
+      authoritative server and was refused.
+
+   internalError
+      The server could not satisfy a request due to misconfiguration or
+      other operational and non-protocol-related reasons.
+
+   locationProfileUnrecognized
+      None of the profiles in the request were recognized by the server
+      (see Section 12).
+
+   locationInvalid
+      The geodetic or civic location in the request was invalid.  For
+      example, the longitude or latitude values fall outside the
+      acceptable ranges.
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 32]
+
+RFC 5222                          LoST                       August 2008
+
+
+   SRSInvalid
+      The spatial reference system (SRS) contained in the location
+      element was not recognized or does not match the location profile.
+
+   loop
+      During a recursive query, the server was about to visit a server
+      that was already in the server list in the <path> element,
+      indicating a request loop.
+
+   notFound
+      The server could not find an answer to the query.
+
+   serverError
+      An answer was received from another LoST server, but it could not
+      be parsed or otherwise understood.  This error occurs only for
+      recursive queries.
+
+   serverTimeout
+      A time out occurred before an answer was received.
+
+   serviceNotImplemented
+      The requested service URN is not implemented and no substitution
+      was available.
+
+   An example is below:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <errors xmlns="urn:ietf:params:xml:ns:lost1"
+     source="resolver.example">
+      <internalError message="Software bug." xml:lang="en"/>
+   </errors>
+
+                  Figure 17: Example of an error response
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 33]
+
+RFC 5222                          LoST                       August 2008
+
+
+13.2.  Warnings
+
+   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 <warnings> element.
+   To provide human-readable text in an appropriate language, the HTTP
+   content negotiation capabilities (see Section 14) MAY be utilized by
+   a server.
+
+   This version of the specification defines the following warnings:
+
+   locationValidationUnavailable
+      The <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.
+
+   serviceSubstitution
+      The <serviceSubstitution> element MAY be returned when a server
+      was not able to fulfill a <findService> request for a given
+      service URN.  For example, a <findService> 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 <service> element in the response provides
+      information about the service URN that refers to the mapping.
+
+   defaultMappingReturned
+      The <defaultMappingReturned> element MAY be returned when a server
+      was not able to fulfill a <findService> request for a given
+      location but is able to respond with a default URI.  For example,
+      a nearby PSAP may be returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 34]
+
+RFC 5222                          LoST                       August 2008
+
+
+   An example of a warning is shown below:
+
+    <?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>
+
+                 Figure 18: Example of a warning response
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 35]
+
+RFC 5222                          LoST                       August 2008
+
+
+13.3.  Redirects
+
+   A LoST server can respond indicating that the querier should redirect
+   the query to another server, using the <redirect> element.  The
+   element includes a 'target' attribute indicating the LoST application
+   unique string (see Section 4) 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 <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.
+
+   An example is below:
+
+   <?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"/>
+
+                 Figure 19: Example of a redirect response
+
+14.  LoST Transport: HTTP
+
+   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.
+
+   When using HTTP [3] and HTTP-over-TLS [4], 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.
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 36]
+
+RFC 5222                          LoST                       August 2008
+
+
+   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
+   Section 13.3 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.
+
+   The HTTP URL is derived from the LoST server name via U-NAPTR
+   application, as discussed above.
+
+15.  Relax NG Schema
+
+   This section provides the Relax NG schema used by the LoST protocol
+   in the compact form.  The verbose form is included in Appendix A.
+
+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 {
+
+
+
+Hardie, et al.              Standards Track                    [Page 37]
+
+RFC 5222                          LoST                       August 2008
+
+
+  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
+
+
+
+Hardie, et al.              Standards Track                    [Page 38]
+
+RFC 5222                          LoST                       August 2008
+
+
+}
+
+##
+##       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 }
+}
+
+##
+
+
+
+Hardie, et al.              Standards Track                    [Page 39]
+
+RFC 5222                          LoST                       August 2008
+
+
+##       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)?,
+
+
+
+Hardie, et al.              Standards Track                    [Page 40]
+
+RFC 5222                          LoST                       August 2008
+
+
+      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 }
+}
+
+
+
+Hardie, et al.              Standards Track                    [Page 41]
+
+RFC 5222                          LoST                       August 2008
+
+
+##
+##       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
+    }
+}
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 42]
+
+RFC 5222                          LoST                       August 2008
+
+
+##
+##       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*
+}
+
+                         Figure 20: RelaxNG schema
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 43]
+
+RFC 5222                          LoST                       August 2008
+
+
+16.  Internationalization Considerations
+
+   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
+   <displayName> element and the 'message' attributes may be displayed
+   to the end user, and they are thus complex types designed for this
+   purpose.
+
+   LoST exchanges information using XML.  All XML processors are
+   required to understand UTF-8 and UTF-16 encodings, and therefore all
+   LoST clients and servers MUST understand UTF-8 and UTF-16 encoded
+   XML.  Additionally, LoST servers and clients MUST NOT encode XML with
+   encodings other than UTF-8 or UTF-16.
+
+17.  IANA Considerations
+
+17.1.  U-NAPTR Registrations
+
+   This document registers the following U-NAPTR application service
+   tag:
+
+      Application Service Tag:  LoST
+
+      Defining Publication:  The specification contained within this
+         document.
+
+   This document registers the following U-NAPTR application protocol
+   tags:
+
+   o  Application Protocol Tag: http
+
+      Defining Publication: RFC 2616 [3]
+
+   o  Application Protocol Tag: https
+
+      Defining Publication: RFC 2818 [4]
+
+17.2.  Content-Type Registration for 'application/lost+xml'
+
+   This specification requests the registration of a new MIME type
+   according to the procedures of RFC 4288 [7] and guidelines in RFC
+   3023 [5].
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 44]
+
+RFC 5222                          LoST                       August 2008
+
+
+   MIME media type name:  application
+
+   MIME subtype name:  lost+xml
+
+   Mandatory parameters:  none
+
+   Optional parameters:  charset
+      Indicates the character encoding of enclosed XML.
+
+   Encoding considerations:  Uses XML, which can employ 8-bit
+      characters, depending on the character encoding used.  See RFC
+      3023 [5], Section 3.2.
+
+   Security considerations:  This content type is designed to carry LoST
+      protocol payloads.
+
+   Interoperability considerations:  None
+
+   Published specification:  RFC 5222
+
+   Applications that use this media type:  Emergency and location-based
+      systems
+
+   Additional information:
+
+      Magic Number:  None
+
+      File Extension:  .lostxml
+
+      Macintosh file type code:  'TEXT'
+
+   Personal and email address for further information:
+      Hannes Tschofenig, Hannes.Tschofenig@nsn.com
+
+   Intended usage:  LIMITED USE
+
+   Author:
+      This specification is a work item of the IETF ECRIT working group,
+      with mailing list address <ecrit@ietf.org>.
+
+   Change controller:
+      The IESG <iesg@ietf.org>
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 45]
+
+RFC 5222                          LoST                       August 2008
+
+
+17.3.  LoST Relax NG Schema Registration
+
+   URI:  urn:ietf:params:xml:schema:lost1
+
+   Registrant Contact:  IETF ECRIT Working Group, Hannes Tschofenig
+      (Hannes.Tschofenig@nsn.com).
+
+   Relax NG Schema:  The Relax NG schema to be registered is contained
+      in Section 15.  Its first line is
+
+   default namespace = "urn:ietf:params:xml:ns:lost1"
+
+   and its last line is
+
+   }
+
+17.4.  LoST Namespace Registration
+
+   URI:  urn:ietf:params:xml:ns:lost1
+
+   Registrant Contact:  IETF ECRIT Working Group, Hannes Tschofenig
+      (Hannes.Tschofenig@nsn.com).
+
+   XML:
+
+BEGIN
+<?xml version="1.0"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
+  "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+  <meta http-equiv="content-type"
+        content="text/html;charset=iso-8859-1"/>
+  <title>LoST Namespace</title>
+</head>
+<body>
+  <h1>Namespace for LoST</h1>
+  <h2>urn:ietf:params:xml:ns:lost1</h2>
+<p>See <a href="http://www.rfc-editor.org/rfc/rfc5222.txt">
+   RFC5222</a>.</p>
+</body>
+</html>
+END
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 46]
+
+RFC 5222                          LoST                       August 2008
+
+
+17.5.  LoST Location Profile Registry
+
+   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 RFC 5226 [2], Standards Action.
+
+   geodetic-2d:
+      Defined in Section 12.2.
+
+   civic:
+      Defined in Section 12.3.
+
+18.  Security Considerations
+
+   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.
+
+   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.
+
+   The use of server identity checks with TLS, as described in Section
+   3.1 of [4], 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.
+
+   Note that the security considerations in [22] 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.
+
+
+
+Hardie, et al.              Standards Track                    [Page 47]
+
+RFC 5222                          LoST                       August 2008
+
+
+   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 [23] for
+   more comprehensive discussion.
+
+   DNS Security (DNSSEC) [20] 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.
+
+   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.
+
+   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.
+
+   A more detailed description of threats and security requirements is
+   provided in [17].  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.
+
+19.  Acknowledgments
+
+   We would like to the thank the following working group members for
+   the detailed review of previous LoST document versions:
+
+   o  Martin Thomson (Review July 2006)
+
+   o  Jonathan Rosenberg (Review July 2006)
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 48]
+
+RFC 5222                          LoST                       August 2008
+
+
+   o  Leslie Daigle (Review September 2006)
+
+   o  Shida Schubert (Review November 2006)
+
+   o  Martin Thomson (Review December 2006)
+
+   o  Barbara Stark (Review January 2007)
+
+   o  Patrik Faltstrom (Review January 2007)
+
+   o  Shida Schubert (Review January 2007 as a designated expert
+      reviewer)
+
+   o  Jonathan Rosenberg (Review February 2007)
+
+   o  Tom Taylor (Review February 2007)
+
+   o  Theresa Reese (Review February 2007)
+
+   o  Shida Schubert (Review February 2007)
+
+   o  James Winterbottom (Review July 2007)
+
+   o  Karl Heinz Wolf (Review May and June 2007)
+
+   We would also like to thank the following working group members for
+   their input to selected design aspects of the LoST protocol:
+
+   o  Leslie Daigle and Martin Thomson (DNS-based LoST discovery
+      procedure)
+
+   o  John Schnizlein (authoritive LoST answers)
+
+   o  Rohan Mahy (display names)
+
+   o  James Polk (error handling)
+
+   o  Ron Watro and Richard Barnes (expiry of cached data)
+
+   o  Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James
+      Winterbottom (indication of PSAP confidence level)
+
+   o  Martin Thomson (service boundary references)
+
+   o  Martin Thomson (service URN in LoST response message)
+
+   o  Clive D.W. Feather, Martin Thomson (validation functionality)
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 49]
+
+RFC 5222                          LoST                       August 2008
+
+
+   o  Roger Marshall (PSAP preference in LoST response)
+
+   o  James Winterbottom, Marc Linsner, Keith Drage, Tom Taylor, Martin
+      Thomson, John Schnizlein, Shida Schubert, Clive D.W. Feather,
+      Richard Stastny, John Hearty, Roger Marshall, Jean-Francois Mule,
+      Pierre Desjardins (location profiles)
+
+   o  Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson,
+      Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list
+      services functionality)
+
+   o  Martin Thomson, Michael Hammer (mapping of services)
+
+   o  Shida Schubert, James Winterbottom, Keith Drage (default service
+      URN)
+
+   o  Otmar Lendl (LoST aggregation)
+
+   o  Tom Taylor (terminology)
+
+   Klaus Darilion and Marc Linsner provided miscellaneous input to the
+   design of the protocol.  Finally, we would like to thank Brian Rosen,
+   who participated in almost every discussion thread.
+
+   Early implementation efforts led to good feedback by two open source
+   implementation groups.  We would like to thank the implementers for
+   their work and for helping us to improve the quality of the
+   specification:
+
+   o  Wonsang Song
+
+   o  Jong-Yul Kim
+
+   o  Anna Makarowska
+
+   o  Krzysztof Rzecki
+
+   o  Blaszczyk Piotr
+
+   We would like to thank Jon Peterson, Dan Romascanu, Lisa Dusseault,
+   and Tim Polk for their IESG review comments.  Blocking IESG comments
+   were also received from Pasi Eronen (succeeding Sam Hartman's review)
+   and Cullen Jennings.  Adjustments have been made to several pieces of
+   text to satisfy these requests for changes, most notably in the
+   Security Considerations and in the discussion of redirection in the
+   presence of overlapping coverage areas.
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 50]
+
+RFC 5222                          LoST                       August 2008
+
+
+20.  References
+
+20.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
+
+   [3]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+   [4]   Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [5]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
+         RFC 3023, January 2001.
+
+   [6]   Peterson, J., "A Presence-based GEOPRIV Location Object
+         Format", RFC 4119, December 2005.
+
+   [7]   Freed, N. and J. Klensin, "Media Type Specifications and
+         Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+   [8]   Daigle, L., "Domain-Based Application Service Location Using
+         URIs and the Dynamic Delegation Discovery Service (DDDS)",
+         RFC 4848, April 2007.
+
+   [9]   Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
+         and Other Well-Known Services", RFC 5031, January 2008.
+
+   [10]  Thomson, M. and J. Winterbottom, "Revised Civic Location Format
+         for Presence Information Data Format Location Object
+         (PIDF-LO)", RFC 5139, February 2008.
+
+   [11]  Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
+         "Geographic information - Geography Markup Language (GML)", OGC
+         Standard OpenGIS 03-105r1, April 2004.
+
+   [12]  Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
+         Schema for use by the Internet Engineering Task Force (IETF)",
+         Candidate OpenGIS Implementation Specification , December 2006.
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 51]
+
+RFC 5222                          LoST                       August 2008
+
+
+20.2.  Informative References
+
+   [13]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
+         PIDF-LO Usage Clarification, Considerations and
+         Recommendations", Work in Progress, February 2008.
+
+   [14]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+         Session Initiation Protocol", RFC 3261, June 2002.
+
+   [15]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
+         Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
+         October 2004.
+
+   [16]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
+         December 2004.
+
+   [17]  Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
+         "Security Threats and Requirements for Emergency Call Marking
+         and Mapping", RFC 5069, January 2008.
+
+   [18]  Schulzrinne, H. and R. Marshall, "Requirements for Emergency
+         Context Resolution with Internet Technologies", RFC 5012,
+         January 2008.
+
+   [19]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
+         Framework", Work in Progress, September 2007.
+
+   [20]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [21]  Rosen, B. and J. Polk, "Best Current Practice for
+         Communications Services in support of Emergency Calling", Work
+         in Progress, February 2008.
+
+   [22]  Daigle, L. and A. Newton, "Domain-Based Application Service
+         Location Using SRV RRs and the Dynamic Delegation Discovery
+         Service (DDDS)", RFC 3958, January 2005.
+
+   [23]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+   [24]  <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/
+         RelaxNG>.
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 52]
+
+RFC 5222                          LoST                       August 2008
+
+
+   [25]  Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
+         Location-to-Service Translation (LoST) Servers Using the
+         Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
+         August 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 53]
+
+RFC 5222                          LoST                       August 2008
+
+
+Appendix A.  Non-Normative RELAX NG Schema in XML Syntax
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <grammar ns="urn:ietf:params:xml:ns:lost1"
+           xmlns="http://relaxng.org/ns/structure/1.0"
+           xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
+           datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
+
+           <start>
+       <a:documentation>
+         Location-to-Service Translation (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">
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 54]
+
+RFC 5222                          LoST                       August 2008
+
+
+               <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>
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 55]
+
+RFC 5222                          LoST                       August 2008
+
+
+       <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"/>
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 56]
+
+RFC 5222                          LoST                       August 2008
+
+
+         </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"/>
+
+
+
+Hardie, et al.              Standards Track                    [Page 57]
+
+RFC 5222                          LoST                       August 2008
+
+
+           </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>
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 58]
+
+RFC 5222                          LoST                       August 2008
+
+
+       <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>
+
+
+
+Hardie, et al.              Standards Track                    [Page 59]
+
+RFC 5222                          LoST                       August 2008
+
+
+       <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>
+
+
+
+Hardie, et al.              Standards Track                    [Page 60]
+
+RFC 5222                          LoST                       August 2008
+
+
+           <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>
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 61]
+
+RFC 5222                          LoST                       August 2008
+
+
+             <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>
+
+
+
+Hardie, et al.              Standards Track                    [Page 62]
+
+RFC 5222                          LoST                       August 2008
+
+
+     </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"/>
+
+
+
+Hardie, et al.              Standards Track                    [Page 63]
+
+RFC 5222                          LoST                       August 2008
+
+
+         </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>
+
+
+
+Hardie, et al.              Standards Track                    [Page 64]
+
+RFC 5222                          LoST                       August 2008
+
+
+     <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>
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 65]
+
+RFC 5222                          LoST                       August 2008
+
+
+       <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>
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 66]
+
+RFC 5222                          LoST                       August 2008
+
+
+           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>
+
+                                 Figure 21
+
+Appendix B.  Examples Online
+
+   The XML examples and Relax NG schemas may be found online [24].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 67]
+
+RFC 5222                          LoST                       August 2008
+
+
+Authors' Addresses
+
+   Ted Hardie
+   Qualcomm, Inc.
+
+   EMail: hardie@qualcomm.com
+
+
+   Andrew Newton
+   American Registry for Internet Numbers
+   3635 Concorde Parkway, Suite 200
+   Chantilly, VA  20151
+   US
+
+   Phone: +1 703 227 9894
+   EMail: andy@hxr.us
+
+
+   Henning Schulzrinne
+   Columbia University
+   Department of Computer Science
+   450 Computer Science Building
+   New York, NY  10027
+   US
+
+   Phone: +1 212 939 7004
+   EMail: hgs+ecrit@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu
+
+
+   Hannes Tschofenig
+   Nokia Siemens Networks
+   Linnoitustie 6
+   Espoo  02600
+   Finland
+
+   Phone: +358 (50) 4871445
+   EMail: Hannes.Tschofenig@nsn.com
+   URI:   http://www.tschofenig.priv.at
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 68]
+
+RFC 5222                          LoST                       August 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.              Standards Track                    [Page 69]
+
-- 
cgit v1.2.3