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

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 5, 2007.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

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

Table of Contents

1.  Introduction
2.  Terminology and Requirements Notation
3.  Overview of Protocol Usage
4.  LoST servers and Their Resolution
5.  The <mapping> Element
    5.1.  The Data Source: 'source', 'sourceId' and 'lastUpdated' Attributes
    5.2.  Validity: The 'expires' Attribute
    5.3.  Describing the Service with the <displayName> Element
    5.4.  The Mapped Service: the <service> Element
    5.5.  Defining the Service Region with the <serviceBoundary> Element
    5.6.  Service Boundaries by Reference: the <serviceBoundaryReference> Element
    5.7.  The Service Number Element
    5.8.  Service URLs: the <uri> Element
6.  Path of a Request: <path> Element
7.  Mapping a Location and Service to URLs: <findService>
    7.1.  Overview
    7.2.  Examples
        7.2.1.  Example Using Geodetic Coordinates
        7.2.2.  Civic Address Mapping Example
    7.3.  Components of the <findService> Request
        7.3.1.  The <location> Element
        7.3.2.  Identifying the Service: The <service> Element
        7.3.3.  Recursion and Iteration
        7.3.4.  Service Boundary
        7.3.5.  Requesting Civic Location Validation
    7.4.  Components of the Mapping Response <findServiceResponse>
        7.4.1.  Overview
        7.4.2.  Civic Address Validation: the <locationValidation> Element
8.  Retrieving the Service Boundary via <getServiceBoundary>
9.  List Services: <listServices>
10.  List Services By Location: <listServicesByLocation>
11.  Location Profiles
    11.1.  Location Profile Usage
    11.2.  Two Dimensional Geodetic Profile
    11.3.  Basic Civic Profile
12.  Errors, Warnings, and Redirects
    12.1.  Errors
    12.2.  Warnings
    12.3.  Redirects
13.  LoST Transport
14.  Relax NG Schema
15.  Internationalization Considerations
16.  IANA Considerations
    16.1.  U-NAPTR Registrations
    16.2.  Content-type registration for 'application/lost+xml'
    16.3.  LoST Relax NG Schema Registration
    16.4.  LoST Namespace Registration
    16.5.  LoST Location Profile Registry
17.  Security Considerations
18.  Acknowledgments
19.  Open Issues
20.  References
    20.1.  Normative References
    20.2.  Informative References
Appendix A.  Non-Normative RELAX NG Schema in XML Syntax
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

Numerous techniques have been specified for the discovery of servers for a particular service, including NAPTR records, SVRLOC and similar protocols. However, there are an important class of services where the specific service instance that is to be connected to depends on the identity of the service and the location of the entity that needs to reach it. An example of this is emergency telecommunications services, where the service instance is a Public Safety Answering Point (PSAP) that has jurisdiction over the location of the user making the call. Here, 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 callers location based on geopolitical boundaries. For this reason, the selected service instance is a function of location and the desired service.

This document describes a protocol for mapping a service identifier [8] (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.) and location information compatible with PIDF-LO (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) [6], namely revised civic location information (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,” February 2007.) [9] and GML (Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, “Geographic information - Geography Markup Language (GML),” April 2004.) [11]) to one or more service URL. Example service URL schemes include sip [13] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), xmpp [14] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.), and tel [15] (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.). While the initial focus is on providing mapping functions for emergency services, it is likely that the protocol is applicable to any service URN. For example, in the United States, the "2-1-1" and "3-1-1" 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 [17] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” August 2006.) 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 (see Section 3.5 of [17] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” August 2006.) for a description of validation). LoST indicates errors in the location data to facilitate debugging and proper user feedback, but also provides best-effort answers.

LoST queries can be resolved recursively or iteratively. To minimize round trips 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").

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 [18] (Schulzrinne, H., “Location-to-URL Mapping Architecture and Framework,” December 2006.).

The query message carries location information and a service identifier encoded as a Uniform Resource Name (URN) (see [8] (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.)) from the LoST client to the LoST server. The LoST server uses its database to map the input values to one or more Uniform Resource Identifiers (URI) and returns those URIs along with optional information, such as hints about the service 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 7 (Mapping a Location and Service to URLs: <findService>), the protocol also allows to retrieve the service boundary (see Section 8 (Retrieving the Service Boundary via <getServiceBoundary>)) and to list the services available for a particular location (see Section 10 (List Services By Location: <listServicesByLocation>)) or supported by a particular server (see Section 9 (List Services: <listServices>)).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 that point to a host providing that service or acting as an intermediary to establish communication with the serving entity. This definition is a generalization of the term "mapping" as used in [17] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” August 2006.), because of the potential for LoST to be used for non-emergency services.

LoST Client and Server:

"LoST client" is the role played by an entity that sends LoST query messages and receives LoST response messages. "LoST server" is the role played by an entity that receives LoST query messages and sends LoST response messages. In recursive operation, the same entity may play both roles. This document also uses the term "authoritative server" to designate an entity that acts in the LoST server role only and successfully resolves the input location and service identifier to a URI or set of URIs.

Service Boundary:

A service boundary is the boundary or set of boundaries of a geographic region, respectively set of geographic regions, within which all locations will map to the same URI or set of URIs for a given service.

Validation:

The term "validation" as used in this document is a concrete realization of the term "location validation" as defined in Section 3.5 of [17] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” August 2006.).

Additional emergency service terminology can be found in [17] (Schulzrinne, H. and R. Marshall, “Requirements for Emergency Context Resolution with Internet Technologies,” August 2006.).

3.  Overview of Protocol Usage

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

<findService> and <findServiceResponse>

This message pattern allows to perform retrieve contact URIs based on location information together with a service identifier. The same query type may also ask for location validation and for service numbers, either integrated into mapping request or separately. The details can be found in Section 7 (Mapping a Location and Service to URLs: <findService>) and Section 7.4 (Components of the Mapping Response <findServiceResponse>).

<getServiceBoundary> and <getServiceBoundaryResponse>

This message pattern allows query for a service boundary. The details can be found in Section 8 (Retrieving the Service Boundary via <getServiceBoundary>).

<listServices> and <listServicesResponse>

This message pattern enables a LoST client to ask a LoST server for the services it supports. The details can be found in Section 9 (List Services: <listServices>).

<listServicesByLocation> and <listServicesByLocationResponse>

This message pattern provides the LoST client with the services that are available for a specific location region. The details can be found in Section 10 (List Services By Location: <listServicesByLocation>).

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.
2. When the client detects that its location has changed sufficiently that it is outside the bounds of the service region.
3. An incoming message at a SIP proxy in a location-based routing scenario that requires a routing decision to be made.
4. When cached mapping information has expired.
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 [19] (Rosen, B. and J. Polk, “Best Current Practice for Communications Services in support of Emergency Calling,” October 2006.), 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 (Validity: The 'expires' Attribute)), or they become invalid if the caller's device moves beyond the boundaries of the service region.

4.  LoST servers and Their Resolution

LoST servers are identified by U-NAPTR/DDDS [10] (Daigle, L., “Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS),” February 2007.) application unique strings, in the form of a DNS name.

An example is 'lostserver.example.com'

Clients need to use the U-NAPTR [10] (Daigle, L., “Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS),” February 2007.) 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.

    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.

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 Data Source: 'source', 'sourceId' and 'lastUpdated' Attributes

The 'source', the 'sourceId' and the 'lastUpdated' attributes uniquely identify a particular mapping record. They are created by the authoritative source for a mapping and 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 datum in 'lastUpdated'.

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

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 canonical UTC representation with the letter 'Z' as the timezone indicator.

5.2.  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. See Section 3 (Overview of Protocol Usage) regarding how this value is to be utilized with a cache. The 'expires' attribute is REQUIRED to be included in the <mapping> element.

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 it is the responsibility of the client to check the 'expires' attribute associated with mapping data returned in a LoST response to detemine whether the mapping is fresh.

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 <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 (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.) [8] in the <service> element of the request, exists for the location indicated, then the LoST server puts the service URN from the request into the <service> element.
2. If, however, the requested service, identified by the service URN (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.) [8] in the <service> element in the request, does not exist for the location indicated, the server can either return an <serviceNotImplemented> (Errors) error or can provide an alternate service that approximates the desired service for that location. In the latter case, the server MUST include a <service> element with the alternative service URN. The choice of service URN is left to local policy, but the alternate service should be able to satisfy the original service request.

The <service> element is optional but may also be required if the mapping is to be digitally signed.

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 (Service Boundaries by Reference: the <serviceBoundaryReference> Element)). 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 different location profile, identified by the 'profile' atribute (see Section 11 (Location Profiles)). If included in a response, the <serviceBoundary> element MUST contain at least one service boundary that uses the same profile as the request. The client only processes the first element that it can understand according to its list of supported location profiles. Thus, elements with geospatial coordinates are alternative descriptions of the same service region, not additive geometries.

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

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.

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

Since geodetic service boundaries may contain thousands of points and thus be quite large, clients may opt to conserve bandwidth and request a reference to the service boundary instead of the value described in Section 5.5 (Defining the Service Region with the <serviceBoundary> Element). 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 (LoST servers and Their Resolution)) identifying the server from where it can be retrieved. The actual value of the service boundary is then retrieved with the getServiceBoundary (Retrieving the Service Boundary via <getServiceBoundary>) 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 per value or to omit the <serviceBoundaryReference> element in the response.

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 the remainder of the mapping has become invalid.

5.7.  The Service Number 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: <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 (LoST servers and Their Resolution)). 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. The <via> element is inserted logically on receipt of the request, so that every server in a recursive query operation is included in the <path> element.

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.

The example in Figure 5 (A <findServiceResponse> civic address answer) 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.  Mapping a Location and Service to URLs: <findService>

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

7.2.  Examples

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

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

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 Deparment, 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.

<?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" version="1">
    <displayName xml:lang="en">
      New York City Police Department
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary profile="geodetic-2d">
      <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
        <p2:exterior>
          <p2:LinearRing>
            <p2:pos>37.775 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4194</p2:pos>
          </p2:LinearRing>
        </p2:exterior>
      </p2:Polygon>
    </serviceBoundary>
    <uri>sip:nypd@example.com</uri>
    <uri>xmpp:nypd@example.com</uri>
    <serviceNumber>911</serviceNumber>
  </mapping>
  <path>
    <via source="authoritative.example"/>
    <via source="resolver.example"/>
  </path>
</findServiceResponse>

7.2.2.  Civic Address Mapping Example

The following is an example of mapping a service to a location much like the example in Section 7.2.1 (Example Using Geodetic Coordinates), 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).

<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1"
  recursive="true" serviceBoundary="value">
  <location
    profile="civic">
    <civicAddress
      xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
      <country>Germany</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>

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 city of Munich) or after January 1, 2007.

<?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" version="1" >
    <displayName xml:lang="de">
      Muenchen Polizei-Abteilung
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary
      profile="urn:ietf:params:lost:location-profile:basic-civic">
      <civicAddress
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
        <country>Germany</country>
        <A1>Bavaria</A1>
        <A3>Munich</A3>
        <PC>81675</PC>
      </civicAddress>
    </serviceBoundary>
    <uri>sip:munich-police@example.com</uri>
    <uri>xmpp:munich-police@example.com</uri>
    <serviceNumber>110</serviceNumber>
  </mapping>
  <path>
    <via source="esgw.ueber-110.de.example"/>
    <via source="polizei.muenchen.de.example"/>
  </path>
</findServiceResponse>

7.3.  Components of the <findService> Request

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

7.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 11 (Location Profiles)). There MUST NOT be more than one location element for each distinct location profile. The order of location objects is significant; the server uses the first location object where it understands the location profile.

7.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 [8] (Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006.).

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

For the queries defined in this document, only 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 (LoST servers and Their Resolution)), i.e., indirection, however, it MUST NOT recurse if the attribute is "false".

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

7.3.5.  Requesting Civic Location Validation

Civic address validation is requested by setting the optional attribute 'validateLocation' to true. If the attribute is omitted, it is assumed to be false. The response is described in Section 7.4.2 (Civic Address Validation: the <locationValidation> Element). The example in Figure 6 (A <findService> query with address validation request) demonstrates address validation, omitting the standard response elements.

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

<?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"
    version="1" >
    <displayName xml:lang="de">
      Muenchen Polizei-Abteilung
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary profile="civic">
      <civicAddress
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
        <country>Germany</country>
        <A1>Bavaria</A1>
        <A3>Munich</A3>
        <PC>81675</PC>
      </civicAddress>
    </serviceBoundary>
    <uri>sip:munich-police@example.com</uri>
    <uri>xmpp:munich-police@example.com</uri>
    <serviceNumber>110</serviceNumber>
  </mapping>
  <locationValidation>
    <valid>country A1 A3 A6</valid>
    <invalid>PC</invalid>
  </locationValidation>
  <path>
    <via source="authoritative.example"/>
    <via source="resolver.example"/>
  </path>
</findServiceResponse>

7.4.  Components of the Mapping Response <findServiceResponse>

7.4.1.  Overview

Mapping responses consist of the <mapping> element (Section 5 (The <mapping> Element)) describing the mapping itself, possibly followed by warnings (Warnings), location validation information (Civic Address Validation: the <locationValidation> Element), and an indication of the path (Path of a Request: <path> Element) the response has taken.

7.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 white space, enumerating the civic location lables used in child elements of the <civicAddress> element. The <valid> element enumerates those civic address elements that have been recognized as valid by the LoST server and that have been used to determine the mapping. The <unchecked> elements enumerates the civic address elements that the server did not check and that were not used in determining the response. The <invalid> element enumerate civic address elements that the server attempted to check, but that did not match the other civic address elements found in the <valid> list.

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 (A <findService> query with address validation request) 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.

8.  Retrieving the Service Boundary via <getServiceBoundary>

As discussed in Section 5.5 (Defining the Service Region with the <serviceBoundary> Element), 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 8 (<findService> request and response with service boundary reference). The client can then retrieve the boundary using the <getServiceBoundary> request and obtains the boundary in the <getServiceBoundaryResponse>, illustrated in the example in Figure 10 (Requesting a service boundary with <getServiceBoundary>). 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.

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

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

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

The <getServiceBoundary> request may also be used to retrieve service boundaries that are expressed as civic addresses, as illustrated in Figure 11 (Civic Address Service Boundary Response).

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

9.  List Services: <listServices>

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

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

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

10.  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 (Location Profiles), and may contain the <service> element. As for <findService>, the server selects the first location element that has a profile the server understands and it can operate either recursively or iteratively; < via> elements track the progress of the request. By its nature, the query can only indicate the services that a particular server can determine, not all possible services that might be offered. Unlike <ListServices>, the answer describes the services available at a specific location, not just those understood by the server.

If the query contains the <service> element, 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 (Path of a Request: <path> Element)) and MUST contain a <serviceList> element, consisting of a whitespace-separated list of service URNs. The query and response are illustrated in Figure 14 (Example of <ListServicesbyLocation> query) and in Figure 15 (Example of <ListServices> response), 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 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>

<?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
  urn:service:sos.suicide
 </serviceList>
 <path>
  <via source="authoritative.example"/>
  <via source="resolver.example"/>
 </path>
</listServicesByLocationResponse>

11.  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 possible to standardize other profiles in the future. The two baseline profiles are:

geodetic-2d:

a simple profile for two-dimensional geodetic location information, as described in Section 11.2 (Two Dimensional Geodetic Profile);

civic:

a profile consisting of civic address location information, as described in Section 11.3 (Basic Civic Profile).

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.

11.1.  Location Profile Usage

A location profile is identified by a token in an IANA-maintained registry (LoST Location Profile Registry). 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 a mandatory 'profile' attribute that indicates the location format of the child elements. The concept of location profiles are described in Section 11 (Location Profiles). 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.

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 conformant to the location profile specified in the 'profile' attribute. When multiple <location> elements are included then it enables the server to send location information compliant with multiple location profiles.

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

1. A client MUST be capable of understanding the response for the baseline profiles it used in the request.
2. If a client sends location information conformant to any location profile other than geodetic-2d or civic, it MUST also send, in the same request, location information conformant to one of the baseline profiles. Otherwise, the server might not be able to understand the request.
3. A client SHOULD NOT send multiple <location> profiles of derived from different baseline profiles. Or said another way, a client should only send location profiles from the same baseline profile in the same query. If a client has location information primarily of geodetic nature and location information primarily of a civic nature, it should send separate requests containing each type of location information.
4. There can only be one instance of each location profile in a query.
5. Servers MUST implement the geodetic-2d and civic profiles.
6. A server uses the first-listed location profile that it understands and ignores the others.
7. If a server receives a request that only contains location information using profiles it does not understand, the server responds with a <locationProfileError> (Errors).
8. The <serviceBoundary> element MUST use the same location profile that was used to retrieve the answer and indicates which profile has been used with the 'profile' attribute.

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

<?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="value">
  <location profile="uber-complex-3d">
    <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
       <p2:pos>37.775 -122.422</p2:pos>
    </p2:Point>
      <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>
    <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
       <p2:pos>-122.422 37.775</p2:pos>
    </p2:Point>
  </location>
  <location profile="geodetic-2d">
    <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
       <p2:pos>37.775 -122.422</p2:pos>
    </p2:Point>
  </location>
  <service>urn:service:sos.police</service>
</findService>

<?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"
    version="1">
    <displayName xml:lang="en">
      New York City Police Department
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary profile="geodetic-2d">
      <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
        <p2:exterior>
          <p2:LinearRing>
            <p2:pos>37.775 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4194</p2:pos>
          </p2:LinearRing>
        </p2:exterior>
      </p2:Polygon>
    </serviceBoundary>
    <uri>sip:nypd@example.com</uri>
  </mapping>
  <path>
    <via source="authoritative.example"/>
    <via source="resolver.example"/>
  </path>
</findServiceResponse>

11.2.  Two Dimensional Geodetic Profile

The geodetic-2d location profile is identified by geodetic-2d. Clients use this profile by placing a <Point> element, as described in Section 7.2.1 of [12] (Reed, C. and M. Thomson, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” December 2006.), within the <location> element. Section 7.2.1 of [12] (Reed, C. and M. Thomson, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” December 2006.) describes 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 altitude.

Servers use this profile by placing a <Polygon> element, as described in Section 7.2.2 of [12] (Reed, C. and M. Thomson, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” December 2006.), within the <serviceBoundary> element. This is defined by the 'polygon' pattern in the LoST schema (see Section 14 (Relax NG Schema)).

With respect to the description in Section 7.2.2 of [12] (Reed, C. and M. Thomson, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” December 2006.) the restriction to 16 points for a polygon is not applicable to this document. With this profile servers MUST use WGS 84 (latitude, longitude), i.e., the srsName set to 'urn:ogc:def:crs:EPSG::4326' where altitude information is omitted. The orientation of the points in the polygon is upward normal as described in Section 7.2.2 of [12] (Reed, C. and M. Thomson, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” December 2006.).

11.3.  Basic Civic Profile

The basic-civic location profile is identified by the token 'civic'. Clients use this profile by placing a <civicAddress> element, defined in [9] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,” February 2007.), within the <location> element.

Servers use this profile by placing a <civicAddress> element, defined in [9] (Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,” February 2007.), within the <serviceBoundary> element.

12.  Errors, Warnings, and Redirects

When a LoST server cannot fulfill a request completely, it can return either an error or a warning, depending on the severity of the problem. It returns an error 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. This document does not define warnings. 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.

12.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. (For HTTP as the underlying protocol, an HTTP 401 error would be returned.)

internalError

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

locationProfileUnrecognized

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

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>

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

This version of the specification does not define any warning elements.

12.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 (LoST servers and Their Resolution)) 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.

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

13.  LoST Transport

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

When using HTTP [3] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) and HTTP-over-TLS [4] (Rescorla, E., “HTTP Over TLS,” May 2000.), LoST requests use the HTTP POST method. All HTTP responses are applicable. The HTTP URL is derived from the LoST server name via U-NAPTR application, as discussed above

14.  Relax NG Schema

This section provides the Relax NG schema used by LoST protocol in the compact form. The verbose form is included in Appendix A (Non-Normative RELAX NG Schema in XML Syntax).

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


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

##
##       The queries.
##
div {
  findService =
    element findService {
      element location { locationInformation }+,
      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 {
      element location { locationInformation }*,
      commonRequestPattern,
      attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
    }
  getServiceBoundary =
    element getServiceBoundary { serviceBoundaryKey, extensionPoint }
}

##
##       The responses.
##
div {
  findServiceResponse =
    element findServiceResponse {
      mapping+, locationValidation?, commonResponsePattern
    }
  listServicesResponse =
    element listServicesResponse { serviceList, commonResponsePattern }
  listServicesByLocationResponse =
    element listServicesByLocationResponse {
      serviceList, commonResponsePattern
    }
  getServiceBoundaryResponse =
    element getServiceBoundaryResponse {
      serviceBoundary, commonResponsePattern
    }
}

##
##       A pattern common to some of the queries.
##
div {
  commonRequestPattern = service, path?, extensionPoint
}

##
##       A pattern common to responses.
##
div {
  commonResponsePattern = warnings*, path, extensionPoint
}

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

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

##
##       Service Boundary Reference
##
div {
  serviceBoundaryReference =
    element serviceBoundaryReference {
      source, serviceBoundaryKey, extensionPoint
    }
  serviceBoundaryKey = attribute key { xsd:token }
}

##
##       Path -
##       Contains a list of via elements -
##       places through which information flowed
##
div {
  path =
    element path {
      element via { source, extensionPoint }+
    }
}

##
##       Expires pattern
##
div {
  expires =
    attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
}

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

##
##       A location-to-service mapping.
##
div {
  mapping =
    element mapping {
      element displayName {
        xsd:string,
        attribute xml:lang { xsd:language }
      }*,
      service,
      (serviceBoundary | serviceBoundaryReference)?,
      element uri { xsd:anyURI }*,
      element serviceNumber {
        xsd:string { 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 {
  errorContainer =
    (badRequest?
     & internalError?
     & serviceSubstitution?
     & forbidden?
     & notFound?
     & loop?
     & serviceNotImplemented?
     & serverTimeout?
     & serverError?
     & locationProfileUnrecognized?),
    extensionPoint,
    source
  errors = element errors { errorContainer }
  warnings = element warnings { errorContainer }
}

##
##       Basic Errors
##
div {

  ##
  ##         Error pattern.
  ##
  basicError = message, extensionPoint
  badRequest = element badRequest { basicError }
  internalError = element internalError { basicError }
  serviceSubstitution = element serviceSubstitution { basicError }
  forbidden = element forbidden { basicError }
  notFound = element notFound { basicError }
  loop = element loop { basicError }
  serviceNotImplemented = element serviceNotImplemented { basicError }
  serverTimeout = element serverTimeout { basicError }
  serverError = element serverError { basicError }
  locationProfileUnrecognized =
    element locationProfileUnrecognized {
      attribute unsupportedProfiles { xsd:NMTOKENS },
      basicError
    }
}

##
##       Redirect.
##
div {

  ##
  ##         Redirect pattern
  ##
  redirect =
    element redirect {
      attribute target { appUniqueString },
      source,
      message,
      extensionPoint
    }
}

##
##       Some common patterns.
##
div {
  message =
    (attribute message { xsd:string },
     attribute xml:lang { xsd:language })?
  service = element service { xsd:anyURI }?
  appUniqueString =
    xsd:string { 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*
}

15.  Internationalization Considerations

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

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

16.  IANA Considerations

16.1.  U-NAPTR Registrations

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

Application Service Tag:

LoST

Defining Publication:

The specification contained within this document.

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

• Application Protocol Tag:

  http

  Defining Publication:

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

• Application Protocol Tag:

  https

  Defining Publication:

  RFC 2818 (Rescorla, E., “HTTP Over TLS,” May 2000.) [4]

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

This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [7] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.) and guidelines in RFC 3023 [5] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.).

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] (Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types,” January 2001.), Section 3.2.

Security considerations:

This content type is designed to carry LoST protocol payloads.

Interoperability considerations:

None

Published specification:

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

Applications which use this media type:

Emergency and Location-based Systems

Additional information:

Magic Number:

None

File Extension:

.lostxml

Macintosh file type code:

'TEXT'

Personal and email address for further information:

Hannes Tschofenig, Hannes.Tschofenig@siemens.com

Intended usage:

LIMITED USE

Author:

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

Change controller:

The IESG <iesg@ietf.org>

16.3.  LoST Relax NG Schema Registration

URI:

urn:ietf:params:xml:ns:lost1

Registrant Contact:

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

Relax NG Schema:

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

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

and its last line is

}

16.4.  LoST Namespace Registration

URI:

urn:ietf:params:xml:ns:lost1

Registrant Contact:

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

XML:

BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
  "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type"
        content="text/html;charset=iso-8859-1"/>
  <title>LoST Namespace</title>
</head>
<body>
  <h1>Namespace for LoST</h1>
  <h2>urn:ietf:params:xml:ns:lost1</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
    [NOTE TO IANA/RFC-EDITOR:
     Please replace XXXX with the RFC number of this
    specification.]</a>.</p>
</body>
</html>
END

16.5.  LoST Location Profile Registry

This document seeks to create a registry of location profile names for the LoST protocol. Profile names are XML tokens. This registry will operate in accordance with RFC 2434 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.) [2], Standards Action.

geodetic-2d:

Defined in Section 11.2 (Two Dimensional Geodetic Profile)

civic:

Defined in Section 11.3 (Basic Civic Profile)

17.  Security Considerations

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

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

Generally, authentication and authorization is not required for mapping queries. If it is, authentication mechanism 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 are provided in [16] (Taylor, T., “Security Threats and Requirements for Emergency Call Marking and Mapping,” July 2006.).

18.  Acknowledgments

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

• Martin Thomson (Review July 2006)
• Jonathan Rosenberg (Review July 2006)
• Leslie Daigle (Review September 2006)
• Shida Schubert (Review November 2006)
• Martin Thomson (Review December 2006)
• Barbara Stark (Review January 2007)
• Patrik Fältström (Review January 2007
• Shida Schubert (Review January 2007 as a designated expert reviewer)
• Jonathan Rosenberg (Review February 2007)
• Tom Taylor (Review February 2007)
• Theresa Reese (Review February 2007)
• Shida Schubert (Review February 2007)

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

• Leslie Daigle and Martin Thomson (DNS-based LoST discovery procedure)
• John Schnizlein (authoritive LoST answers)
• Rohan Mahy (display names)
• James Polk (error handling)
• Ron Watro and Richard Barnes (expiry of cached data)
• Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James Winterbottom (Indication of PSAP Confidence Level)
• Martin Thomson (service boundary references)
• Martin Thomson (service URN in LoST response message)
• Cullen Jennings (service boundaries)
• Clive D.W. Feather, Martin Thomson (Validation Functionality)
• Roger Marshall (PSAP Preference in LoST response)
• James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-Francois Mule, Pierre Desjardins (Location Profiles)
• Michael Hammer, Patrik Fältström, Stastny Richard, Thomson, Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, Keith (List Services functionality)
• Thomson, Martin, Michael Hammer (Mapping of Services)
• Shida Schubert, James Winterbottom, Keith Drage (default service URN)
• Otmar Lendl (LoST aggregation)
• 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.

19.  Open Issues

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

20.  References

20.1. Normative References

20.2. Informative References

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

<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost1"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<a:documentation>
      Location-to-Service Translation Protocol (LoST)
      A LoST XML instance has three request types, each with
      a cooresponding response type: find service, list services,
      and get service boundary.
</a:documentation>
<choice>
<ref name="findService" />
<ref name="listServices" />
<ref name="listServicesByLocation" />
<ref name="getServiceBoundary" />
<ref name="findServiceResponse" />
<ref name="listServicesResponse" />
<ref name="listServicesByLocationResponse" />
<ref name="getServiceBoundaryResponse" />
<ref name="errors" />
<ref name="redirect" />
</choice>
</start>
<div>
<a:documentation>
      The queries.
    </a:documentation>

    <define name="findService">
      <element name="findService">
        <oneOrMore>
          <element name="location">
            <ref name="locationInformation" />
          </element>
        </oneOrMore>
        <ref name="commonRequestPattern" />
        <optional>
          <attribute name="validateLocation">
            <data type="boolean" />
            <a:defaultValue>false</a:defaultValue>
          </attribute>
        </optional>
        <optional>
          <attribute name="serviceBoundary">
            <choice>
              <value>reference</value>
              <value>value</value>
            </choice>
            <a:defaultValue>reference</a:defaultValue>
          </attribute>
        </optional>
        <optional>
          <attribute name="recursive">
            <data type="boolean" />
              <a:defaultValue>false</a:defaultValue>
          </attribute>
        </optional>
      </element>
    </define>

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

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

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

  </div>

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


    <define name="findServiceResponse">
      <element name="findServiceResponse">
        <oneOrMore>
          <ref name="mapping" />
        </oneOrMore>
        <optional>
          <ref name="locationValidation" />
        </optional>
        <ref name="commonResponsePattern" />
      </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" />
      </element>
    </define>

    <define name="getServiceBoundaryResponse">
      <element name="getServiceBoundaryResponse">
        <ref name="serviceBoundary"/>
        <ref name="commonResponsePattern" />
      </element>
    </define>

  </div>

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

    <define name="commonRequestPattern">
      <ref name="service" />
      <optional>
        <ref name="path" />
      </optional>
      <ref name="extensionPoint" />
    </define>
  </div>

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

    <define name="commonResponsePattern">
      <zeroOrMore>
        <ref name="warnings" />
      </zeroOrMore>
      <ref name="path" />
      <ref name="extensionPoint" />
    </define>
  </div>

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

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

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

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

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

    <define name="serviceBoundaryReference">

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

    <define name="serviceBoundaryKey">
      <attribute name="key">
        <data type="token" />
      </attribute>
    </define>

  </div>

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

    <define name="path">
      <element name="path">
        <oneOrMore>
          <element name="via">
            <ref name="source" />
            <ref name="extensionPoint" />
          </element>
        </oneOrMore>
      </element>
    </define>
  </div>

  <div>
    <a:documentation>
      Expires pattern
    </a:documentation>

    <define name="expires">
      <attribute name="expires">
        <choice>
          <data type="dateTime"/>
          <value>NO-CACHE</value>
          <value>NO-EXPIRATION</value>
        </choice>
      </attribute>
    </define>
  </div>

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

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

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

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

  </div>

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

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

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

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

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

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

  </div>

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

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

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

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

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

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

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

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

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

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

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

    <define name="locationProfileUnrecognized">
      <element name="locationProfileUnrecognized">
        <attribute name="unsupportedProfiles">
          <data type="NMTOKENS" />
        </attribute>
        <ref name="basicError"/>
      </element>
    </define>

  </div>

  <div>
    <a:documentation>
      Redirect.
    </a:documentation>

    <define name="redirect">
      <a:documentation>
        Redirect pattern
      </a:documentation>
      <element name="redirect">
        <attribute name="target">
          <ref name="appUniqueString" />
        </attribute>
        <ref name="source" />
        <ref name="message" />
        <ref name="extensionPoint" />
      </element>
    </define>

  </div>

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

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

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

    <define name="appUniqueString">
      <data type="string">
        <param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
      </data>
    </define>

    <define name="source">
      <attribute name="source">
        <ref name="appUniqueString" />
      </attribute>
    </define>

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

  </div>

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

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


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

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

  </div>

</grammar>

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

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

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

Intellectual Property

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

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

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

Acknowledgment

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