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
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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.
本文档描述了一个基于XML的协议，用于将服务标识符和大地测量或城市位置信息映射到服务联系人URI。特别是，它可用于确定紧急服务的位置适当的公共安全应答点（PSAP）。
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
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
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
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
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.
诸如命名机构指针（NAPTR）记录和服务位置协议（SLP）之类的协议可用于发现提供特定服务的服务器。但是，对于一类重要的服务，适当的特定服务实例取决于服务的标识和需要访问它的实体的地理位置。紧急电信服务就是一个重要的例子；这里，服务实例是一个公共安全应答点（PSAP），它对拨打电话的用户的位置具有管辖权。所需的PSAP不一定是拓扑上最接近调用方的PSAP，甚至不是最接近调用方的PSAP；相反，它是根据管辖范围为呼叫者的位置服务的。
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.
本文档描述了将与状态信息数据格式位置对象（PIDF-LO）[6]兼容的服务标识符和位置信息映射到一个或多个服务URI的协议。服务标识符采用[9]中描述的服务URN的形式。此处的位置信息包括经修订的城市位置信息[10]和PIDF-LO剖面的子集[13]，因此包括为GML[11]定义的地理形状[12]。示例服务URI方案包括sip[14]、xmpp[15]和tel[16]。虽然最初的重点是为应急服务提供映射功能，但该协议可能适用于其他服务URN。例如，在美国，“2-1-1”和“3-1-1”服务编号的位置与紧急服务的服务行为相似。
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满足映射协议的要求[18]。LoST提供了许多操作，以将位置和服务URN映射到服务URL和相关信息为中心。丢失的地图查询可以包含civic或大地测量位置信息。如[18]第3.5节所述，对于公民地址，“丢失”可以表示公民地址的哪些部分已知有效或无效，从而提供地址验证。LoST表示位置数据中的错误，以便于调试和正确的用户反馈，但也提供了最佳答案。
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").
丢失的查询可以递归或迭代地解决。为了最大限度地减少往返并提供对网络故障的鲁棒性，LoST支持缓存单个映射，并指示将返回相同答案的区域（“服务区域”）。
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.
如本文档所定义，丢失的消息在HTTP和HTTPS协议交换中传输，便于使用TLS保护请求和响应的完整性和机密性。
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].
本文档重点介绍映射客户端和映射服务器之间的协议。其他功能，如发现映射服务器、数据复制和整体映射服务器体系结构在单独的文档中进行了描述[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).
查询消息携带位置信息和编码为统一资源名（URN）（参见[9]）的服务标识符，从丢失的客户端传输到丢失的服务器。丢失的服务器使用其数据库将输入值映射到一个或多个统一资源标识符（URI），并在向丢失的客户端发送的响应消息中返回这些URI以及可选信息，例如关于服务边界的提示。如果服务器无法自行解析查询，则它可能会依次查询另一台服务器或返回另一台丢失服务器的地址（由丢失的服务器名称标识）。除了第8节中描述的映射功能外，该协议还允许检索服务边界（参见第9节），并列出特定位置（参见第11节）可用的或特定服务器支持的服务（参见第10节）。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
映射：映射是一个将位置和服务标识符作为输入并返回一个或多个URI的过程。这些URI可以指向提供该服务的主机，也可以指向将请求路由到最终目的地的主机。该定义是[18]中使用的术语“映射”的概括，因为LoST可用于非紧急服务。
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.
丢失的服务器：如果主机接收丢失的查询消息并发送丢失的响应消息，则它将充当丢失的服务器。在递归操作中，同一实体可能既是客户机又是服务器。
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.
权威丢失服务器：权威服务器仅充当服务器，并成功地将输入位置和服务标识符解析为URI或URI集。
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.
服务边界：服务边界限定了一个区域，其中所有位置都映射到给定服务的同一个服务URI或URI集。服务边界可以由几个不连续的几何形状组成。
Validation: The term "validation" describes the behavior defined as "location validation" in Section 3.5 of [18].
验证：术语“验证”描述了[18]第3.5节中定义为“位置验证”的行为。
Additional emergency service terminology can be found in [18].
其他应急服务术语见[18]。
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.
<findService>和<findServiceResponse>丢失的客户端根据位置信息和带有此请求和响应的服务标识符检索联系人URI。同一查询类型还可能要求位置验证和服务编号，可以与映射请求结合使用，也可以单独使用。详情见第8节。
<getServiceBoundary> and <getServiceBoundaryResponse> A LoST client obtains a service boundary with this request and response, as described in Section 9.
<getServiceBoundary>和<getServiceBoundaryResponse>丢失的客户端通过该请求和响应获得服务边界，如第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.
<listServices>和<listServicesResponse>通过此请求和响应，丢失的客户端可以找到丢失的服务器支持哪些服务，如第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.
<listServicesByLocation>和<listServicesByLocationResponse>丢失的客户端可以通过此请求和响应确定特定位置区域可用的服务。第11节描述了细节。
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;
1. 当客户端最初启动或连接到网络时；
2. when the client detects that its location has changed sufficiently that it is outside the bounds of the service region;
2. 当客户端检测到其位置已发生足够的变化，以致其位于服务区域的边界之外时；
3. when a SIP message arrives at a SIP proxy performing location-based call routing;
3. 当SIP消息到达执行基于位置的呼叫路由的SIP代理时；
4. when cached mapping information has expired; and
4. 当缓存的映射信息过期时；和
5. when invoking a particular service. At that time, a client may omit requests for service boundaries or other auxiliary information.
5. 调用特定服务时。此时，客户机可能会忽略对服务边界或其他辅助信息的请求。
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.
特定于服务的最佳当前实践（BCP）文档（如[21]）控制客户机是否在需要映射服务之前调用映射服务，或者是否依赖缓存的答案。缓存项在其到期时过期（请参阅第5.2节），或者，如果调用方的设备移动到服务区域的边界之外，缓存项将失效。特定于服务的最佳当前实践文档还可以提供最适合服务的联系人URI方案的指导。作为一套通用指南，应避免使用不提供实际启动联系方法机制的URI方案（示例包括数据、信息、cid和标记），因为将这些引用转换为联系机制需要一层间接寻址，这会使整个机制更加脆弱。在使用之前，还应该仔细考虑临时注册的URI方案，因为它们可能会在核心语义中发生变化。
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'.
丢失的服务器由U-NAPTR/DDDS（启用URI的NAPTR/Dynamic Delegation Discovery Service）[8]应用程序唯一字符串以DNS名称的形式标识。例如“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.
客户端需要使用下面描述的U-NAPTR[8]规范来获取适用丢失服务的URI（指示主机和协议）。在本文档中，仅定义了HTTP和HTTPS URL方案。请注意，HTTP URL可以是任何有效的HTTP URL，包括包含路径元素的URL。
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.
以下两个DNS条目显示了“example.com”到HTTPS URL的U-NAPTR解析https://lostserv.example.com/secure 或者HTTP URLhttp://lostserver.example.com，首选前者。
example.com.
example.com。
IN NAPTR 100 10 "u" "LoST:https"
"!.*!https://lostserver.example.com/secure!" ""
IN NAPTR 100 10 "u" "LoST:https"
"!.*!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http"
"!.*!http://lostserver.example.com!" ""
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].
客户端通过超出本规范范围的方式（如SIP配置和DHCP）了解丢失的服务器的主机名[25]。
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.
<mapping>元素是LoST中的核心数据元素，描述服务区域和关联的服务url。其属性和元素在下面的小节中描述。
5.1. The Mapping Data Source: 'source', 'sourceId', and 'lastUpdated' Attributes
5.1. 映射数据源的属性为：“源”、“源ID”和“LastUpdate”
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'.
“source”、“sourceId”和“lastUpdated”属性唯一标识特定映射记录。它们是由权威源为映射创建的，并且在从缓存提供映射服务时从不进行修改。所有<mapping>元素都需要这三个属性。接收器可以将映射替换为另一个具有相同“源”和“源ID”且最近时间为“LastUpdate”的映射。
The 'source' attribute contains a LoST application unique string identifying the authoritative generator of the mapping (Section 4).
“source”属性包含一个丢失的应用程序唯一字符串，用于标识映射的权威生成器（第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.
“sourceId”属性标识特定映射，并包含不透明令牌，该令牌在权威源为该特定服务维护的所有不同映射中必须是唯一的。例如，通用唯一标识符（UUID）是一种合适的格式。
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.
“lastUpdated”属性描述了由“source”和“sourceId”组合标识的映射的特定实例上次更改的时间。此属性的内容具有时区形式的XML数据类型dateTime，使用带有字母“Z”的规范UTC表示形式作为时区指示符。
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.
“expires”属性包含映射无效的绝对时间。此属性的内容是一个时间分区的XML类型dateTime，以规范表示。<mapping>元素必须包含“expires”属性。
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.
或者，此属性可能包含“无缓存”和“无过期”的值，而不是日期时间值。值“NO-CACHE”表示不应缓存映射。“NO-EXPIRATION”的值表示映射未过期。
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.
有时，如果服务器无法到达权威服务器或服务器无法返回可用答案，则可能会强制服务器返回过期的映射。客户端和服务器可以缓存映射，以便它们至少有一些可用信息。具有此类陈旧信息的缓存服务器应在每次客户端请求映射时重新尝试查询。由于过期映射将作为非错误/非警告响应返回给客户端，因此客户端必须检查“expires”属性；如果映射已过期，则客户端的本地策略将确定是放弃应答并稍后重试，还是使用可能过时的响应。
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.
零个或多个<displayName>元素使用适合显示给人类用户的字符串来描述服务，每个元素都带有“xml:lang”属性的注释，该属性包含一个语言标记以帮助呈现文本。
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:
必需的<service>元素标识此映射适用的服务。当丢失的服务器在响应消息中设置<service>元素时，需要区分两种情况：
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.
1. 如果请求的<service>元素中的service URN[9]标识的请求服务存在于指定的位置，则丢失的服务器将服务URN从请求复制到<service>元素中。
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
2. 但是，如果请求中<service>元素中的service URN[9]标识的请求服务在指定位置不存在，则服务器可以返回<serviceNotImplemented>（第13.1节）错误，或者可以提供近似于该位置所需服务的替代服务
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.
地方在后一种情况下，服务器必须包含带有备用服务URN的<service>元素。服务URN的选择由本地策略决定，但是备用服务应该能够满足原始服务请求。
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.
响应可以指示返回的服务URL与实际查询中相同的区域，即所谓的服务区域。服务区域可通过数值或参考来表示（见第5.6节）。如果客户机移动到服务区域之外并希望获取当前服务数据，则会发送一个包含其当前位置的新查询。服务区域由一个或多个<serviceBoundary>元素中的值描述，每个元素根据特定的位置配置文件进行格式化，由“配置文件”属性标识（参见第12节）<serviceBoundary>根据不同位置配置文件格式化的元素是相同区域的替代表示，而不是彼此相加；这允许客户端只了解其中一种配置文件类型，以确保它具有serviceBoundary的完整视图。然而，在一个服务边界元素内，可能存在多个附加位置；这是必要的，因为一些<serviceBoundary>区域无法用单个形状或位置轻松表示。如果包含在响应中，<serviceBoundary>元素必须至少包含一个使用与请求相同配置文件的服务边界。
A service boundary is requested by the client, using the 'serviceBoundary' attribute in the request with the value set to "value".
客户端使用请求中的“serviceBoundary”属性请求服务边界，该属性的值设置为“value”。
5.6. Service Boundaries by Reference: The <serviceBoundaryReference> Element
5.6. 按引用划分的服务边界：<serviceBoundaryReference>元素
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.
由于大地测量服务边界可能包含数千个点，因此可能相当大，客户可能希望通过请求参考服务边界而不是第5.5节中描述的值来节省带宽。服务边界的标识符作为<serviceBoundaryReference>元素的属性返回，同时返回一个丢失的应用程序唯一字符串（参见第4节），该字符串标识可从中检索服务边界的服务器。然后使用getServiceBoundary（第9节）请求检索服务边界的实际值。
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.
客户端使用请求中的“serviceBoundary”属性请求对服务边界的引用，该属性的值设置为“reference”。丢失的服务器可能会根据本地策略决定按值返回服务边界，或者在响应中忽略<serviceBoundaryReference>元素。
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.
该标识符是具有至少128位熵的随机令牌，并且可以假设为全局唯一。它唯一地引用特定边界。如果边界发生变化，则必须选择新的标识符。由于这些属性，接收映射响应的客户端可以简单地检查它是否已经具有具有该标识符的边界副本。如果是这样，它可以跳过与服务器检查边界是否已更新。由于服务边界可能会在较长时间内保持不变，可能会超过服务URL的正常生存期，因此这种方法可以避免仅仅因为映射的其余部分已变得无效而不必要地刷新边界信息。
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.
服务编号在可选的<serviceNumber>元素中返回。它包含一串数字，*和#，使用12键拨号键盘的设备上的用户可以使用这些数字来访问特定的服务。
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'.
响应返回一个或多个<uri>元素中的服务url。URL必须是绝对URL。URL的顺序没有特别的意义。每个URL方案最多只能出现一次，但允许同时包含协议的安全版本和常规版本，如“http”和“https”或“sip”和“sips”。
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.
为了防止循环并允许跟踪请求和响应路径，所有允许递归的请求都包括一个<path>元素，该元素包含一个或多个<via>元素，每个元素都拥有一个包含丢失的应用程序唯一字符串的属性（见第4节）。<via>元素的顺序对应于丢失服务器的顺序，即第一个<via>元素标识最初从发出请求的客户端接收请求的服务器。递归查询操作中的每个服务器都包含在<path>元素中，包括第一个接收它的服务器。
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.
回答请求而不是转发请求的服务器（如权威服务器）会将<path>元素逐字复制到响应中。当响应穿过服务器链回到查询客户机时，<path>元素不会在响应中被修改。
If a query is answered iteratively, the querier includes all servers that it has already contacted.
如果以迭代方式回答查询，查询器将包括它已经联系的所有服务器。
When a cached mapping is returned, then the <path> element cached together with the mapping is returned.
当返回缓存的映射时，将返回与映射一起缓存的<path>元素。
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.
图4中的示例表明，答案由位于esgw.ueber-110.de.example的丢失服务器提供给客户机，该服务器从位于polizei.muenchen.de.example的（权威）丢失服务器获得答案。
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.
几个请求可以提供一个或多个<location>元素，服务器可以从中进行选择。对于客户机来说，能够确定在生成结果时实际使用了哪一个是非常有用的。为此，<location>标记必须包含唯一标识<location>元素的“id”属性。标识符的格式留给客户机；例如，它可以使用位置信息的散列。服务器返回它在<locationUsed>标记中使用的<location>元素的标识符。
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.
<findService>查询构成了丢失功能的核心，将城市或大地测量位置映射到URL和相关数据。在给出一个例子之后，我们列举了查询和响应的元素。
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).
以下是使用大地坐标将服务映射到与警察相关的服务（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">
<?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>
<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>
</findService>
Figure 1: A <findService> geodetic query
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.
给定上述查询，服务器将使用服务以及与该服务相关的信息进行响应。在下面的示例中，服务器已将客户端为警察服务提供的位置映射到纽约市警察局，指示客户端可以通过URI“sip:nypd@example.com“和”xmpp:nypd@example.com". 服务器还为客户端提供了该服务的大地测量二维边界。地图最后一次更新是在2006年11月1日，2007年1月1日到期。如果客户机的位置更改超出了给定的服务边界或已达到到期时间，则可能需要根据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">
<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>
<?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
Figure 2: A <findServiceResponse> geodetic answer
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).
下面的示例显示了如何将服务映射到一个位置，非常类似于第8.2.1节中的示例，但使用公民地址位置信息。在本例中，客户机请求与警察相关的服务（urn:service:sos.police）以及特定的公民地址（位于德国慕尼黑一条名为Otto Hahn Ring的街道上的6号房屋）。
<?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>
<?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
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.
给定上述查询，服务器将使用服务以及与该服务相关的信息进行响应。在下面的示例中，服务器已将客户端为警察服务提供的位置映射到Muenchen Polizei Abteilung，指示客户端可以通过URI sip:munich与他们联系-police@example.com和xmpp：慕尼黑-police@example.com. 服务器还为客户端提供了此服务的公民地址边界（慕尼黑市）。权威来源“polizei.muenchen.de.example”于2006年11月1日对地图进行了最后更新，并于2007年1月1日到期。这指示客户在其位置超出给定服务边界（即，超出指定的慕尼黑地区）或在2007年1月1日之后发生变化时重新查询信息。
<?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>
<?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
Figure 4: A <findServiceResponse> civic address answer
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.
<findService>请求包括属性和元素，这些属性和元素控制请求是以迭代方式还是递归方式处理，是否执行位置验证，以及响应中可能包含哪些元素。
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
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
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.
对于每个不同的位置配置文件。位置元素的顺序是显著的；服务器使用它理解位置配置文件的第一个位置元素。
The type of service desired is specified by the <service> element. It contains service URNs from the registry established in [9].
所需的服务类型由<service>元素指定。它包含[9]中建立的注册表中的服务URN。
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.
LoST可以在递归或迭代模式下逐个请求地运行。在递归模式下，丢失的服务器代表请求者发起查询，并将结果返回给请求者。
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".
对于本文档中定义的查询，只有丢失的<findService>和<listServicesByLocation>查询可以是递归的，如“recursive”属性所示。值“true”表示递归查询，当省略属性时，默认值为“false”。无论属性如何，服务器都可以通过提供丢失的应用程序唯一字符串（参见第4节）来回答查询，即间接寻址；但是，如果属性为“false”，则它不能递归。
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.
LoST<mapping>元素可以通过值或引用来描述服务边界。对于地理空间（多边形）边界和边界很少更改的情况，返回服务边界引用通常更节省空间，但会引发额外的<getServiceBoundary>请求。查询者可以在<findService>请求中使用“serviceBoundary”属性表示对一种或另一种模态的偏好，但服务器将最终决定是否返回引用或值。
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.
通过将可选属性“validateLocation”设置为true，请求公民地址验证。如果省略该属性，则假定该属性为false。第8.4.2节描述了响应。图5中的示例演示了地址验证。如果服务器在请求中提供的位置中选择大地测量位置，则忽略该属性。
<?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>
<?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
Figure 5: A <findService> query with address validation request
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="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>
<?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
图6:带有地址验证信息的<findServiceResponse>消息
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.
映射响应由描述映射本身的<Mapping>元素（第5节）组成，后面可能有警告（第13.2节）、位置验证信息（第8.4.2节）和响应路径指示（第6节）。
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.
服务器可以在其响应中指出它已识别为有效的civic地址元素、已忽略的civic地址元素以及已检查并发现无效的civic地址元素。如果请求中的“validateLocation”属性为true，则服务器应包含此信息，但服务器的本地策略可能允许忽略此信息。每个元素都包含一个由空格分隔的标记列表，列举<civicAddress>元素的子元素中使用的civic位置标签。<valid>元素枚举丢失的服务器已识别为有效且用于确定映射的civic address元素。<unchecked>元素枚举服务器未检查且在确定响应时未使用的civic address元素。<invalid>元素枚举服务器试图检查的公民地址元素，但与<valid>列表中找到的其他公民地址元素不匹配。未在<valid>、<invalid>或<unchecked>元素中列出的Civic location标记属于未检查标记的类别。
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.
图5和图6所示的示例表明令牌“country”、“A1”、“A3”和“A6”已由丢失的服务器验证。服务器认为<PC>元素中的邮政编码81675对此位置无效。“HNO”标记属于未检查位置标记的类别。
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.
如第5.5节所述，<findServiceResponse>可以在“serviceBoundary”属性中返回可用于检索服务边界的全局唯一标识符，而不是按值返回边界。图7和图8中的示例显示了这一点。然后，客户端可以使用<getServiceBoundary>请求检索边界，并在<getServiceBoundaryResponse>中获取边界，如图9和图10中的示例所示。客户端向<serviceBoundaryReference>元素的“服务器”属性中标识的服务器发出请求。这些请求总是定向到权威服务器，并且不会递归。
<?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>
<?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
图7:<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">
<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>
<?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
图8:<findServiceResponse>带有服务边界引用的消息
<?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
key="7214148E0433AFE2FA2D48003D31172E"/>
<?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>
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>
<?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：大地测量服务边界响应
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.
丢失的客户机可以向丢失的服务器询问其了解的服务列表，主要用于诊断目的。查询不包含位置信息，因为它只是提供服务器可以查找哪些服务的指示，而不是是否为特定区域提供特定服务。通常，答案中只包含顶级服务，这意味着支持所有子服务。由于查询是由被查询的服务器应答的，因此没有递归或间接的概念。下面的<listServicesByLocation>（第11节）查询可用于确定是否为特定位置提供了特定服务。图11显示了一个请求和响应示例。
<?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"?>
<listServices
xmlns="urn:ietf:params:xml:ns:lost1">
<service>urn:service:sos</service>
</listServices>
Figure 11: Example of <ListServices> query
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>
<?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>
Figure 12: Example of <ListServicesResponse>
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.
丢失的客户端可以向丢失的服务器请求它知道的特定区域的服务列表。<listServicesByLocation>查询包含一个或多个<location>元素，每个元素来自不同的位置配置文件（第12节），并且可能包含<service>元素。对于<findService>，服务器选择第一个位置元素，该元素具有服务器理解的概要文件，并且可以递归或迭代操作<via>元素跟踪请求的进度。该查询指示服务器可以从其所属的林结构中枚举的服务。由于LoST并不假定所有潜在服务类型都是一个单一的总体组织，因此在一个地理区域内可能存在可用的服务，这些服务可以由连接到其他森林结构的其他LoST服务器来描述。例如，一个区域的应急服务林可能不同于位于同一区域内的商业服务林。
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.
如果查询包含<service>元素，则丢失的服务器只返回查询服务中可用于提供位置的直接子服务。如果<service>元素不存在，丢失的服务将返回它所知道的提供位置的所有顶级服务。
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.
服务器使用<listServicesByLocationResponse>响应响应此查询。此响应可能包含<via>元素（参见第6节），并且必须包含<serviceList>元素，该元素由以空格分隔的服务urn列表组成。查询和响应分别如图13和图14所示。
<?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>
<?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
Figure 13: Example of <ListServicesbyLocation> query
<?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>
<?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
Figure 14: Example of <ListServicesByLocationResponse> response
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:
LoST在请求中的<location>元素和响应中的<serviceBoundary>元素中使用位置信息。这种位置信息可以以多种方式表示。这种多样性可能会导致互操作性问题，其中请求或响应分别包含服务器或客户端无法理解的格式的位置信息。为了实现互操作性，本文件定义了两个强制的基线位置配置文件，以定义位置信息的传输方式。将来可以标准化其他配置文件。基线概况如下：
geodetic-2d: a profile for two-dimensional geodetic location information, as described in Section 12.2;.
大地测量-2d：第12.2节所述的二维大地测量位置信息的剖面；。
civic: a profile consisting of civic address location information, as described in Section 12.3.
公民：由公民地址位置信息组成的档案，如第12.3节所述。
Requests and responses containing <location> or <serviceBoundary> elements MUST contain location information in exactly one of the two baseline profiles, in addition to zero or more additional profiles. The ordering of location information indicates a preference on the part of the sender.
包含<location>或<serviceBoundary>元素的请求和响应除了零个或多个附加配置文件外，还必须在两个基线配置文件中的一个中包含位置信息。位置信息的顺序表示发送方的偏好。
Standards action is required for defining new profiles. A location profile MUST define:
定义新配置文件需要标准操作。位置配置文件必须定义：
1. The token identifying it in the LoST location profile registry.
1. 在丢失位置配置文件注册表中标识它的令牌。
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.
2. 请求中要使用的XML的正式定义，即<location>元素的XML子元素的枚举和定义。
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.
3. 响应中要使用的XML的正式定义，即<serviceBoundary>元素的XML子元素的枚举和定义。
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.
4. 将大地测量2d或civic用作基线纵断面的声明。有必要明确声明基线纵断面，因为未来纵断面可能是大地测量和城市位置信息的组合。
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.
位置配置文件由IANA维护的注册表中的令牌标识（第17.5节）。客户端发送符合位置配置文件的位置信息，服务器响应符合该位置配置文件的位置信息。
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.
当丢失的客户端发送提供位置信息的<findService>请求时，它包括一个或多个<location>元素。<location>元素带有一个可选的“profile”属性，该属性指示子元素的位置格式。客户机可能会获取不符合其识别的概要文件的位置信息，或者可能无法将XML映射到概要文件。在这种情况下，客户机可能会忽略profile属性，服务器应该尽其所能解释XML位置数据，如果无法解释，则返回“locationProfileUnrecognized”错误。
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.
第12节描述了位置剖面的概念。由于能够指定多个<location>元素，客户端能够在同一请求中传递多个位置配置文件的位置信息。
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.
当丢失的服务器发送包含位置信息的响应时，它使用<serviceBoundary>元素，就像客户端使用<location>元素一样。每个<serviceBoundary>元素包含符合“配置文件”属性中指定的位置配置文件的位置信息。响应可能包含不同<location>元素的多个映射或边界，但受以下限制。
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.
1. 客户机必须能够理解其在请求中使用的基线配置文件的响应。
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.
2. 如果客户机发送的位置信息符合本文档中描述的位置配置文件以外的任何位置配置文件，则它还必须在同一请求中发送符合其中一个基线配置文件的位置信息。否则，服务器可能无法理解该请求。
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.
3. 客户端不得发送多个从不同基线配置文件派生的<location>对象。换句话说，客户机只能根据查询中的同一基线配置文件发送位置对象，但除了某些其他配置文件之外，它还可能在基线配置文件之后包含位置元素。
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.
4. 如果客户同时拥有主要为大地测量性质的位置信息和主要为城市性质的位置信息，则必须发送包含每种类型位置信息的单独请求。
5. There can only be one instance of each location profile in a query.
5. 查询中每个位置配置文件只能有一个实例。
6. Servers MUST implement all profiles described in this document.
6. 服务器必须实现本文档中描述的所有配置文件。
7. A server uses the first-listed location profile that it understands and ignores the others.
7. 服务器使用它理解的第一个列出的位置配置文件，并忽略其他位置配置文件。
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).
8. 如果服务器收到的请求仅包含使用其不理解的配置文件的位置信息，则服务器将以<locationProfileError>响应（第13.1节）。
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.
9. <serviceBoundary>元素必须使用与检索答案相同的位置配置文件，并指示哪个配置文件与“profile”属性一起使用。
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.
这些规则允许使用尚未指定的位置配置文件，同时确保基线互操作性。以图15和16所示的场景为例。客户端X的固件已升级，以支持“尚未标准化的prism配置文件”位置配置文件。客户端X向服务器Y发送位置信息，服务器Y不理解“尚未标准化的prism配置文件”位置配置文件。如果客户端X也使用geodetic-2D基线配置文件发送位置信息，那么服务器Y仍然能够理解请求并提供可理解的响应，尽管位置信息可能不如预期的精确或表达。这是可能的，因为客户端X和服务器Y都了解基线配置文件。
<?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>
<?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
图15：具有基线概要文件互操作性的<findServices>查询示例
<?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>
<?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
图16：具有基线概要文件互操作性的<findServiceResponse>消息示例
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):
“大地测量-2d”位置剖面由标记“大地测量-2d”标识。客户端和服务器通过将以下位置形状放入<serviceBoundary>或<location>元素来使用此配置文件（除非另有说明）：
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.
点：<Point>元素在[13]的第5.2.1节中描述。[13]第5.2.1节还显示了具有二维位置（纬度和经度）或三维位置（纬度、经度和高度）的<Point>的规范。客户端可以使用三维位置，服务器可以通过忽略高度值将三维位置解释为二维位置。<Point>元素未放置在<serviceBoundary>元素中。
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.
多边形：<Polygon>元素在[13]的第5.2.2节中进行了描述。[12]第7.2.2节中包含的多边形16点限制不适用于本文件。
Circle: The <Circle> element is described in Section 5.2.3 of [13].
圆：<Circle>元素在[13]的第5.2.3节中进行了描述。
Ellipse: The <Ellipse> element is described in Section 5.2.4 of [13].
椭圆：<椭圆>元素在[13]的第5.2.4节中进行了描述。
ArcBand: The <ArcBand> element is described in Section 5.2.5 of [13].
ArcBand:<ArcBand>元素在[13]的第5.2.5节中进行了描述。
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).
当客户机在<location>元素中使用<Polygon>、<Circle>、<Ellipse>或<ArcBand>元素时，这表示它将通过适合于形状任何部分的查询结果得到满足。由服务器选择合适的匹配算法。如果形状扩展到多个服务区域，则服务器可能返回多个<mapping>元素。服务器不需要返回所有可能的<mapping>元素以避免拒绝服务攻击，在拒绝服务攻击中，客户端呈现跨越大量服务边界的查询（例如，呈现覆盖整个美国的形状）。
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
如果服务器不返回多个<mapping>元素，但形状跨越服务边界，则丢失的服务器选择的匹配算法可能会返回与形状的一部分匹配但与特定点特定的结果不匹配的结果。客户可以始终从形状中选择一个点以避免出现这种情况。在哪些情况下
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.
它通常不知道自己在给定形状内的位置。在紧急服务用例中，这可能导致通过LoST提供的URI联系的PSAP被要求将呼叫转发给其邻居之一；这是整个应急响应系统的预期部分。在非紧急服务用例中，服务部署模型应将此问题作为供应模型的一部分加以考虑，因为丢失的服务器中的数据和用于映射的算法的组合确定了在使用重叠多个服务区域的形状时返回的联系人URI。
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.
当此位置纵断面的大地测量位置信息放置在<serviceBoundary>元素中时，具有地理空间坐标的元素是同一服务区域的替代描述，而不是添加的几何图形。
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.
基本civic位置配置文件由标记“civic”标识。客户端通过在<location>元素中放置[10]中定义的<civicAddress>元素来使用此配置文件。
Servers use this profile by placing a <civicAddress> element, defined in [10], within the <serviceBoundary> element.
服务器通过在<serviceBoundary>元素中放置[10]中定义的<civicAddress>元素来使用此配置文件。
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.
响应可能包含多个配置文件为“civic”的<serviceBoundary>元素。每个<serviceBoundary>元素都描述了一组服务边界内的公民地址，即所有文本上与提供的公民地址元素匹配的地址，而不管其他地址元素的值如何。如果某个位置与任何<serviceBoundary>元素匹配，则该位置属于映射的服务边界。因此，响应可能包含多个<serviceBoundary>元素，这些元素具有civic和/或大地测量位置剖面。
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.
当丢失的服务器无法完全满足请求时，它可能会返回错误或警告，具体取决于问题的严重程度。如果不能为查询返回有用的响应，它将返回一个<errors>元素。如果能够部分响应，它将返回一个<warnings>元素作为另一个响应元素的一部分，但是响应可能不是客户机所期望的。对于这两个元素，“source”属性命名最初生成错误或警告的服务器，例如权威服务器。除非另有说明，否则以下所有元素都可以是错误或警告，具体取决于是否包含默认响应（如映射）。
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.
LoST定义错误模式，在RELAXNG模式中定义为<errors>元素。此模式定义了一个包含人类可读文本的“message”属性和一个表示人类可读文本语言的“xml:lang”属性。<errors>元素中包含一个或多个此类错误元素。
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.
badRequest服务器无法解析或理解请求，例如，因为XML格式不正确。
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.
internalError由于配置错误或其他与操作和非协议相关的原因，服务器无法满足请求。
locationProfileUnrecognized None of the profiles in the request were recognized by the server (see Section 12).
LocationProfile未识别服务器未识别请求中的任何配置文件（请参阅第12节）。
locationInvalid The geodetic or civic location in the request was invalid. For example, the longitude or latitude values fall outside the acceptable ranges.
locationInvalid请求中的大地测量或城市位置无效。例如，经度或纬度值超出可接受的范围。
SRSInvalid The spatial reference system (SRS) contained in the location element was not recognized or does not match the location profile.
SRSInvalid位置元素中包含的空间参考系（SRS）未被识别或与位置配置文件不匹配。
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.
循环在递归查询期间，服务器将要访问<path>元素中已在服务器列表中的服务器，这表示请求循环。
notFound The server could not find an answer to the query.
notFound服务器找不到查询的答案。
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.
serverError从另一台丢失的服务器接收到应答，但无法对其进行分析或理解。此错误仅适用于递归查询。
serverTimeout A time out occurred before an answer was received.
服务器超时在收到应答之前发生超时。
serviceNotImplemented The requested service URN is not implemented and no substitution was available.
serviceNotImplemented请求的服务URN未实现，没有可用的替换。
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>
<?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
图17：错误响应的示例
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.
响应可能包含零个或多个警告。此模式定义了一个包含人类可读文本的“message”属性和一个表示人类可读文本语言的“xml:lang”属性。<warnings>元素中包含一个或多个此类警告元素。为了以适当的语言提供人类可读的文本，服务器可以利用HTTP内容协商能力（参见第14节）。
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.
locationValidationUnavailable当服务器希望通知客户端它无法完成位置验证请求时，可能会返回<locationValidationUnavailable>元素。此警告允许服务器在发送此异常状态的信号时返回映射信息。
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.
serviceSubstitution当服务器无法满足给定服务URN的<findService>请求时，可能会返回<serviceSubstitution>元素。例如，<findService>请求乌拉圭某个位置的“urn:service:sos.police”服务urn可能会导致丢失的服务返回“urn:service:sos”服务urn的映射，因为乌拉圭不使用子服务警察、消防和救护车。如果返回此警告，则响应中的<service>元素提供有关引用映射的服务URN的信息。
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.
defaultMappingReturned当服务器无法满足给定位置的<findService>请求，但能够使用默认URI响应时，可能会返回<defaultMappingReturned>元素。例如，可以返回附近的PSAP。
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>
<?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
图18：警告响应示例
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.
丢失的服务器可以响应，指示查询者应该使用<redirect>元素将查询重定向到另一台服务器。元素包括一个“target”属性，该属性指示客户端下一步应该联系的丢失的应用程序唯一字符串（参见第4节），以及一个“source”属性，该属性指示生成重定向响应的服务器，以及一个“message”属性，解释重定向响应的原因。在递归查询期间，接收<redirect>响应的服务器可以决定是要遵循重定向，还是只将响应返回给其上游查询器。处理重定向查询的服务器返回的响应中的“expires”值表示可能需要新查询的最早时间（参见第5.2节）。对于位置和服务的同一元组的查询不应定向到在此之前发出重定向的服务器。
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"/>
<?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
图19：重定向响应的示例
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.
LoST需要一个底层协议传输机制来承载请求和响应。本文档定义了LoST over HTTP和LoST over HTTP over TLS的使用。提醒客户机和服务器开发人员，完全支持RFC2616HTTP设施是意料之中的事。如果丢失的客户机或服务器重新实现HTTP，而不是使用可用的服务器或客户机代码作为基础，则必须仔细注意完全的互操作性。其他传输机制留待将来的文档处理。可用的传输机制是通过使用丢失的U-NAPTR应用程序确定的。在支持内容类型指示的协议中，LoST使用媒体类型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.
使用HTTP[3]和HTTP over TLS[4]时，丢失的请求使用HTTP POST方法。HTTP请求必须使用缓存控制响应指令“no Cache”禁用HTTP级缓存，即使缓存已配置为向客户端请求返回过时响应。
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.
所有丢失的响应，包括指示丢失警告或错误的响应，都以2xx响应形式进行，通常为200（正常）。其他2xx响应，特别是203（非权威信息），可以由忽略缓存指令的HTTP缓存返回。3xx、4xx和5xx HTTP响应代码表示HTTP请求本身失败或被重定向；这些响应不包含任何丢失的XML元素。3xx响应不同于第13.3节中描述的重定向；第13.3节中的重定向操作发生在丢失的服务器处理请求之后。如果HTTP层重定向是通用的，则第13.3节中描述的丢失服务器重定向可能是特定于特定服务的，或者是丢失服务器进行其他处理的结果。
The HTTP URL is derived from the LoST server name via U-NAPTR application, as discussed above.
HTTP URL是通过U-NAPTR应用程序从丢失的服务器名称派生的，如上所述。
This section provides the Relax NG schema used by the LoST protocol in the compact form. The verbose form is included in Appendix A.
本节以紧凑形式提供丢失协议使用的RELAXNG模式。详细表格见附录A。
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
default namespace ns1 = "urn:ietf:params:xml:ns:lost1"
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
##
## 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
##
## 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 {
##
## The queries.
##
div {
findService =
element findService {
requestLocation,
commonRequestPattern,
attribute validateLocation {
xsd:boolean >> a:defaultValue [ "false" ]
}?,
attribute serviceBoundary {
("reference" | "value") >> a:defaultValue [ "reference" ]
}?,
attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
}
listServices = element listServices { commonRequestPattern }
listServicesByLocation =
element listServicesByLocation {
requestLocation,
commonRequestPattern,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
}
getServiceBoundary =
element getServiceBoundary { serviceBoundaryKey, extensionPoint }
}
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
}
}
##
## The responses.
##
div {
findServiceResponse =
element findServiceResponse {
mapping+, locationValidation?, commonResponsePattern, locationUsed
}
listServicesResponse =
element listServicesResponse { serviceList, commonResponsePattern }
listServicesByLocationResponse =
element listServicesByLocationResponse {
serviceList, commonResponsePattern, locationUsed
}
getServiceBoundaryResponse =
element getServiceBoundaryResponse {
serviceBoundary, commonResponsePattern
}
}
##
## A pattern common to some of the queries.
##
div {
commonRequestPattern = service, path?, extensionPoint
##
## A pattern common to some of the queries.
##
div {
commonRequestPattern = service, path?, extensionPoint
}
}
##
## A pattern common to responses.
##
div {
commonResponsePattern = warnings*, path, extensionPoint
}
##
## A pattern common to responses.
##
div {
commonResponsePattern = warnings*, path, extensionPoint
}
##
## Location in Requests
##
div {
requestLocation =
element location {
attribute id { xsd:token },
locationInformation
}+
}
##
## Location in Requests
##
div {
requestLocation =
element location {
attribute id { xsd:token },
locationInformation
}+
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
##
## Location Information
##
div {
locationInformation =
extensionPoint+,
attribute profile { xsd:NMTOKEN }?
}
##
## Service Boundary
##
div {
serviceBoundary = element serviceBoundary { locationInformation }+
}
##
## Service Boundary
##
div {
serviceBoundary = element serviceBoundary { locationInformation }+
}
##
## Service Boundary Reference
##
div {
serviceBoundaryReference =
element serviceBoundaryReference {
source, serviceBoundaryKey, extensionPoint
}
serviceBoundaryKey = attribute key { xsd:token }
}
##
## 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 }+
}
}
## 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 }
}?
}
##
## Location Used
##
div {
locationUsed =
element locationUsed {
attribute id { xsd:token }
}?
}
##
## Expires pattern
##
div {
expires =
attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
}
##
## Expires pattern
##
div {
expires =
attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
}
##
## A QName list
##
div {
qnameList = list { xsd:QName* }
}
##
## 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)?,
##
## A location-to-service mapping.
##
div {
mapping =
element mapping {
element displayName {
xsd:string,
attribute xml:lang { xsd:language }
}*,
service,
(serviceBoundary | serviceBoundaryReference)?,
element uri { xsd:anyURI }*,
element serviceNumber {
xsd:token { pattern = "[0-9*#]+" }
}?,
extensionPoint,
expires,
attribute lastUpdated { xsd:dateTime },
source,
attribute sourceId { xsd:token },
message
}
}
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
}
}
##
## 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 }
}
##
## Errors and Warnings Container.
##
div {
exceptionContainer =
(badRequest?
& internalError?
& serviceSubstitution?
& defaultMappingReturned?
& forbidden?
& notFound?
& loop?
& serviceNotImplemented?
& serverTimeout?
& serverError?
& locationInvalid?
& locationProfileUnrecognized?),
extensionPoint,
source
errors = element errors { exceptionContainer }
warnings = element warnings { exceptionContainer }
}
##
## Basic Exceptions
##
div {
##
## 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
}
}
##
## 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.
##
div {
##
## Redirect pattern
##
redirect =
element redirect {
attribute target { appUniqueString },
source,
message,
extensionPoint
}
}
##
## Redirect pattern
##
redirect =
element redirect {
attribute target { appUniqueString },
source,
message,
extensionPoint
}
}
##
## Some common patterns.
##
div {
message =
(attribute message { xsd:token },
attribute xml:lang { xsd:language })?
service = element service { xsd:anyURI }?
appUniqueString =
xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
source = attribute source { appUniqueString }
serviceList =
element serviceList {
list { xsd:anyURI* }
}
}
##
## 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 {
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
##
## Any element not in the LoST namespace.
##
notLost = element * - (ns1:* | ns1:*) { anyElement }
##
## 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 wildcard pattern for including any element
## from any other namespace.
##
anyElement =
(element * { anyElement }
| attribute * { text }
| text)*
##
## A point where future extensions
## (elements from other namespaces)
## can be added.
##
extensionPoint = notLost*
}
##
## A point where future extensions
## (elements from other namespaces)
## can be added.
##
extensionPoint = notLost*
}
Figure 20: RelaxNG schema
图20：松弛模式
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.
丢失的协议主要用于机器对机器的通信；因此，它的大部分元素都是不用于人类直接消费的代币。如果将这些令牌呈现给最终用户，则可能需要进行一些本地化。<displayName>元素的内容和“message”属性可以显示给最终用户，因此它们是为此目的而设计的复杂类型。
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.
LoST使用XML交换信息。所有XML处理器都需要理解UTF-8和UTF-16编码，因此所有丢失的客户端和服务器都必须理解UTF-8和UTF-16编码的XML。此外，丢失的服务器和客户端不得使用UTF-8或UTF-16以外的编码对XML进行编码。
This document registers the following U-NAPTR application service tag:
本文档注册了以下U-NAPTR应用程序服务标签：
Application Service Tag: LoST
应用程序服务标签：丢失
Defining Publication: The specification contained within this document.
定义出版物：本文件中包含的规范。
This document registers the following U-NAPTR application protocol tags:
本文件注册了以下U-NAPTR应用协议标签：
o Application Protocol Tag: http
o 应用程序协议标记：http
Defining Publication: RFC 2616 [3]
定义出版物：RFC 2616[3]
o Application Protocol Tag: https
o 应用程序协议标签：https
Defining Publication: RFC 2818 [4]
定义出版物：RFC 2818[4]
This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [7] and guidelines in RFC 3023 [5].
本规范要求根据RFC 4288[7]的程序和RFC 3023[5]中的指南注册新的MIME类型。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: lost+xml
MIME子类型名称：丢失+xml
Mandatory parameters: none
强制参数：无
Optional parameters: charset Indicates the character encoding of enclosed XML.
可选参数：字符集表示封闭XML的字符编码。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [5], Section 3.2.
编码注意事项：使用XML，它可以使用8位字符，具体取决于所使用的字符编码。参见RFC 3023[5]，第3.2节。
Security considerations: This content type is designed to carry LoST protocol payloads.
安全注意事项：此内容类型旨在承载丢失的协议有效负载。
Interoperability considerations: None
互操作性注意事项：无
Published specification: RFC 5222
已发布规范：RFC 5222
Applications that use this media type: Emergency and location-based systems
使用此媒体类型的应用程序：紧急和基于位置的系统
Additional information:
其他信息：
Magic Number: None
神奇数字：无
File Extension: .lostxml
文件扩展名：.lostxml
Macintosh file type code: 'TEXT'
Macintosh file type code: 'TEXT'translate error, please retry
Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@nsn.com
更多信息的个人和电子邮件地址：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>.
作者：本规范是IETF ECRIT工作组的一个工作项，具有邮件列表地址<ecrit@ietf.org>.
Change controller:
The IESG <iesg@ietf.org>
Change controller:
The IESG <iesg@ietf.org>
URI: urn:ietf:params:xml:schema:lost1
URI: urn:ietf:params:xml:schema:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com).
注册人联系人：IETF ECRIT工作组，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
Relax NG模式：要注册的Relax NG模式包含在第15节中。它的第一行是
default namespace = "urn:ietf:params:xml:ns:lost1"
default namespace = "urn:ietf:params:xml:ns:lost1"
and its last line is
最后一行是
}
}
URI: urn:ietf:params:xml:ns:lost1
URI: urn:ietf:params:xml:ns:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@nsn.com).
注册人联系人：IETF ECRIT工作组，Hannes Tschofenig（Hannes。Tschofenig@nsn.com).
XML:
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
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
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.
此文档为丢失的协议创建位置配置文件名称的注册表。配置文件名称是XML标记。该登记处将按照RFC 5226[2]，标准行动进行操作。
geodetic-2d: Defined in Section 12.2.
大地测量-2d：定义见第12.2节。
civic: Defined in Section 12.3.
公民：定义见第12.3节。
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.
服务映射构成了整个系统的一部分，整个系统面临着多种威胁。能够获取服务联系URI的攻击者可以使用这些URI试图中断这些服务。阻止查找联系人URI的攻击者可能会损害此类服务的可访问性。可以窃听请求此查找的通信的攻击者可以猜测是否存在紧急情况及其性质，并可能利用此情况对呼叫者发起物理攻击。
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.
为了避免攻击者修改查询或其结果，必须实现并使用传输层安全性（TLS）。对于客户端对服务器的查询和服务器之间的查询，建议使用；后一个建议是通过替换缓存丢失服务器的答案来帮助避免丢失缓存中毒攻击。
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.
还建议使用TLS服务器身份检查，如[4]第3.1节所述。忽略服务器身份检查会使攻击者伪装成丢失的服务器，因此，只有在获得任何答案时才应使用这种方法，即使是从潜在恶意丢失的服务器，而不是关闭连接（因此根本得不到任何答案）。与服务器证书比较的主机名是URI中的主机名，而不是用作NAPTR解析输入的DNS名称。
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.
请注意，[22]中的安全注意事项建议将NAPTR解析的输入与证书进行比较，而不是与输出（URI中的主机名）进行比较。之所以没有选择这种方法，是因为在紧急服务用例中，部署可能会看到大量U-NAPTR算法的输入解析到单个服务器，通常由本地紧急服务机构运行。在这种情况下，根据丢失的服务器提供的证书检查NAPTR解决方案的输入是不切实际的，因为使用该解决方案的组织列表会很大，可能会发生快速变化，并且丢失的服务器操作员不知道。
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的攻击，因为攻击者可能会更改NAPTR记录。这些攻击包括，例如，截取客户端和递归名称服务器之间的DNS数据包、DNS缓存中毒以及递归名称服务器的故意修改；有关更全面的讨论，请参见[23]。
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.
DNS安全（DNSSEC）[20]可用于防范这些威胁。虽然DNSSEC未完全部署，但用户应意识到风险，尤其是在本地递归名称服务器或客户端与本地递归名称服务器之间的网络不可信的环境中请求NAPTR记录时。
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.
无法使用DNSSEC且不愿意信任没有DNSSEC的DNS解析的丢失部署无法使用基于NATPR的丢失服务器发现。当合适的配置机制可用时，一种可能是直接配置丢失的服务器URI（而不是用于NAPTR解析的域名）。在非紧急服务中应用丢失服务的未来规范也可能指定额外的发现机制和名称匹配语义。
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.
通常，丢失的服务器不需要验证或授权呈现映射查询的客户端。如果这样做，则可以使用底层传输机制的身份验证，例如HTTP基本身份验证和摘要身份验证。基本身份验证只能与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.
[17]中提供了对威胁和安全要求的更详细描述。LoST非紧急服务使用中的威胁和安全要求可能与此处描述的有很大不同。例如，攻击者可能通过返回将用户定向到特定服务提供商的服务映射信息来获取金钱利益。在新环境中部署LoST之前，应对特定于该环境的威胁和需求进行彻底分析，并就适当的缓解措施作出决定。
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 马丁·汤姆森（2006年7月评论）
o Jonathan Rosenberg (Review July 2006)
o 乔纳森·罗森伯格（2006年7月评论）
o Leslie Daigle (Review September 2006)
o 莱斯利·戴格尔（2006年9月评论）
o Shida Schubert (Review November 2006)
o Shida Schubert（2006年11月评论）
o Martin Thomson (Review December 2006)
o 马丁·汤姆森（2006年12月评论）
o Barbara Stark (Review January 2007)
o 芭芭拉·斯塔克（2007年1月评论）
o Patrik Faltstrom (Review January 2007)
o Patrik Faltstrom（2007年1月回顾）
o Shida Schubert (Review January 2007 as a designated expert reviewer)
o Shida Schubert（2007年1月作为指定专家评审员评审）
o Jonathan Rosenberg (Review February 2007)
o 乔纳森·罗森伯格（2007年2月评论）
o Tom Taylor (Review February 2007)
o 汤姆·泰勒（2007年2月评论）
o Theresa Reese (Review February 2007)
o 特里萨·里斯（2007年2月评论）
o Shida Schubert (Review February 2007)
o Shida Schubert（2007年2月评论）
o James Winterbottom (Review July 2007)
o 詹姆斯·温特巴顿（2007年7月评论）
o Karl Heinz Wolf (Review May and June 2007)
o 卡尔·海因茨·沃尔夫（2007年5月和6月评论）
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 Leslie Daigle和Martin Thomson（基于DNS的丢失发现过程）
o John Schnizlein (authoritive LoST answers)
o John Schnizlein（权威性迷失答案）
o Rohan Mahy (display names)
o Rohan Mahy（显示名称）
o James Polk (error handling)
o 詹姆斯·波尔克（错误处理）
o Ron Watro and Richard Barnes (expiry of cached data)
o Ron Watro和Richard Barnes（缓存数据的过期）
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James Winterbottom (indication of PSAP confidence level)
o Stephen Edge、Keith Drage、Tom Taylor、Martin Thomson和James Winterbottom（PSAP信心水平的指标）
o Martin Thomson (service boundary references)
o Martin Thomson（服务边界参考）
o Martin Thomson (service URN in LoST response message)
o Martin Thomson（丢失响应消息中的服务URN）
o Clive D.W. Feather, Martin Thomson (validation functionality)
o Clive D.W.Feather，Martin Thomson（验证功能）
o Roger Marshall (PSAP preference in LoST response)
o Roger Marshall（失去响应时的PSAP偏好）
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 詹姆斯·温特巴顿、马克·林斯纳、基思·德拉格、汤姆·泰勒、马丁·汤姆森、约翰·施尼兹莱因、希达·舒伯特、克莱夫·德瓦·费瑟、理查德·斯塔斯尼、约翰·哈迪、罗杰·马歇尔、让·弗朗索瓦·穆尔、皮埃尔·德贾尔丁（地点简介）
o Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson, Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list services functionality)
o Michael Hammer、Patrik Faltstrom、Richard Stastny、Martin Thomson、Roger Marshall、Tom Taylor、Spencer Dawkins、Keith Drage（列表服务功能）
o Martin Thomson, Michael Hammer (mapping of services)
o Martin Thomson，Michael Hammer（服务映射）
o Shida Schubert, James Winterbottom, Keith Drage (default service URN)
o Shida Schubert、James Winterbottom、Keith Drage（默认服务URN）
o Otmar Lendl (LoST aggregation)
o Otmar Lendl（丢失聚合）
o Tom Taylor (terminology)
o 汤姆·泰勒（术语）
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.
Klaus Darilion和Marc Linsner为协议的设计提供了各种输入。最后，我们要感谢Brian Rosen，他几乎参与了所有的讨论。
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 宋元生
o Jong-Yul Kim
o 金钟郁
o Anna Makarowska
o 安娜·马卡罗夫斯卡
o Krzysztof Rzecki
o Krzysztof Rzecki
o Blaszczyk Piotr
o 布拉斯齐克·皮奥特
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.
我们要感谢Jon Peterson、Dan Romascanu、Lisa Dusseault和Tim Polk对IESG审查的评论。Pasi Eronen（接替Sam Hartman的审查）和Cullen Jennings也提出了阻止IESG的意见。已对若干文本进行了调整，以满足这些更改请求，最显著的是在安全考虑方面以及在存在重叠覆盖区域的情况下对重定向的讨论方面。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[2] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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.
[3] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[4] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[5] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[6] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[6] Peterson，J.，“基于状态的GEOPRIV定位对象格式”，RFC 4119，2005年12月。
[7] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[7] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[8] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[8] Daigle，L.，“使用URI和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 48482007年4月。
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[9] Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，2008年1月。
[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[10] Thomson，M.和J.Winterbottom，“状态信息数据格式位置对象（PIDF-LO）的修订公民位置格式”，RFC 5139，2008年2月。
[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.
[11] Cox，S.，Daisey，P.，Lake，R.，Portele，C.，和A.Whiteside，“地理信息-地理标记语言（GML）”，OGC标准OpenGIS 03-105r1，2004年4月。
[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.
[12] Reed，C.和M.Thomson，“互联网工程任务组（IETF）使用的GML 3.1.1 PIDF-LO形状应用模式”，候选OpenGIS实施规范，2006年12月。
[13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Work in Progress, February 2008.
[13] Winterbottom，J.，Thomson，M.，和H.Tschofenig，“GEOPRIV PIDF-LO使用说明，注意事项和建议”，正在进行的工作，2008年2月。
[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.
[14] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[15] Saint Andre，P.，Ed.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 39212004年10月。
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[16] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[17] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[17] Taylor，T.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，2008年1月。
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[18] Schulzrinne，H.和R.Marshall，“利用互联网技术解决紧急情况的要求”，RFC 5012，2008年1月。
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", Work in Progress, September 2007.
[19] Schulzrinne，H.，“位置到URL映射架构和框架”，正在进行的工作，2007年9月。
[20] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[20] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[21] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, February 2008.
[21] Rosen，B.和J.Polk，“支持紧急呼叫的通信服务当前最佳实践”，正在进行的工作，2008年2月。
[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.
[22] Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[23] Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/ RelaxNG>.
[24] <http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/ 松弛>。
[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.
[25] Schulzrinne，H.，Polk，J.，和H.Tschofenig，“使用动态主机配置协议（DHCP）发现位置到服务转换（丢失）服务器”，RFC 52232008年8月。
<?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">
<?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
<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>
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>
<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">
<define name="findService">
<element name="findService">
<ref name="requestLocation"/>
<ref name="commonRequestPattern"/>
<optional>
<attribute name="validateLocation">
<data type="boolean"/>
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="serviceBoundary">
<choice>
<value>reference</value>
<value>value</value>
</choice>
<a:defaultValue>reference</a:defaultValue>
</attribute>
</optional>
<optional>
<attribute name="recursive">
<data type="boolean"/>
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<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="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="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>
<define name="getServiceBoundary">
<element name="getServiceBoundary">
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
</div>
<div>
<a:documentation>
The responses.
</a:documentation>
<div>
<a:documentation>
The responses.
</a:documentation>
<define name="findServiceResponse">
<element name="findServiceResponse">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<optional>
<ref name="locationValidation"/>
</optional>
<ref name="commonResponsePattern"/>
<ref name="locationUsed"/>
</element>
</define>
<define name="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="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="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>
<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>
<div>
<a:documentation>
A pattern common to some of the queries.
</a:documentation>
<define name="commonRequestPattern">
<ref name="service"/>
<optional>
<ref name="path"/>
<define name="commonRequestPattern">
<ref name="service"/>
<optional>
<ref name="path"/>
</optional>
<ref name="extensionPoint"/>
</define>
</div>
</optional>
<ref name="extensionPoint"/>
</define>
</div>
<div>
<a:documentation>
A pattern common to responses.
</a:documentation>
<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>
<define name="commonResponsePattern">
<zeroOrMore>
<ref name="warnings"/>
</zeroOrMore>
<ref name="path"/>
<ref name="extensionPoint"/>
</define>
</div>
<div>
<a:documentation>
Location in Requests
</a:documentation>
<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>
<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>
<div>
<a:documentation>
Location Information
</a:documentation>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<optional>
<attribute name="profile">
<data type="NMTOKEN"/>
<define name="locationInformation">
<oneOrMore>
<ref name="extensionPoint"/>
</oneOrMore>
<optional>
<attribute name="profile">
<data type="NMTOKEN"/>
</attribute>
</optional>
</define>
</div>
</attribute>
</optional>
</define>
</div>
<div>
<a:documentation>
Service Boundary
</a:documentation>
<div>
<a:documentation>
Service Boundary
</a:documentation>
<define name="serviceBoundary">
<oneOrMore>
<element name="serviceBoundary">
<ref name="locationInformation"/>
</element>
</oneOrMore>
</define>
</div>
<define name="serviceBoundary">
<oneOrMore>
<element name="serviceBoundary">
<ref name="locationInformation"/>
</element>
</oneOrMore>
</define>
</div>
<div>
<a:documentation>
Service Boundary Reference
</a:documentation>
<div>
<a:documentation>
Service Boundary Reference
</a:documentation>
<define name="serviceBoundaryReference">
<define name="serviceBoundaryReference">
<element name="serviceBoundaryReference">
<ref name="source"/>
<ref name="serviceBoundaryKey"/>
<ref name="extensionPoint"/>
</element>
</define>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<div>
<a:documentation>
A QName list
</a:documentation>
<define name="qnameList">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</define>
</div>
<define name="qnameList">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</define>
</div>
<div>
<a:documentation>
A location-to-service mapping.
</a:documentation>
<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>
<define name="mapping">
<element name="mapping">
<zeroOrMore>
<element name="displayName">
<data type="string"/>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</element>
</zeroOrMore>
<ref name="service"/>
<optional>
<choice>
<ref name="serviceBoundary"/>
<ref name="serviceBoundaryReference"/>
</choice>
</optional>
<zeroOrMore>
<element name="uri">
<data type="anyURI"/>
</element>
</zeroOrMore>
<optional>
<element name="serviceNumber">
<data type="token">
<param name="pattern">[0-9*#]+</param>
</data>
</element>
</optional>
<ref name="extensionPoint"/>
<ref name="expires"/>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<ref name="source"/>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<ref name="message"/>
</element>
</define>
</div>
<ref name="source"/>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<ref name="message"/>
</element>
</define>
</div>
<div>
<a:documentation>
Location validation
</a:documentation>
<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>
<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>
<div>
<a:documentation>
Errors and Warnings Container.
</a:documentation>
<define name="exceptionContainer">
<interleave>
<optional>
<ref name="badRequest"/>
</optional>
<optional>
<define name="exceptionContainer">
<interleave>
<optional>
<ref name="badRequest"/>
</optional>
<optional>
<ref name="internalError"/>
</optional>
<optional>
<ref name="serviceSubstitution"/>
</optional>
<optional>
<ref name="defaultMappingReturned"/>
</optional>
<optional>
<ref name="forbidden"/>
</optional>
<optional>
<ref name="notFound"/>
</optional>
<optional>
<ref name="loop"/>
</optional>
<optional>
<ref name="serviceNotImplemented"/>
</optional>
<optional>
<ref name="serverTimeout"/>
</optional>
<optional>
<ref name="serverError"/>
</optional>
<optional>
<ref name="locationInvalid"/>
</optional>
<optional>
<ref name="locationProfileUnrecognized"/>
</optional>
</interleave>
<ref name="extensionPoint"/>
<ref name="source"/>
</define>
<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="errors">
<element name="errors">
<ref name="exceptionContainer"/>
</element>
</define>
<define name="warnings">
<element name="warnings">
<ref name="exceptionContainer"/>
</element>
</define>
<define name="warnings">
<element name="warnings">
<ref name="exceptionContainer"/>
</element>
</define>
</div>
</div>
<div>
<a:documentation>
Basic Exceptions
</a:documentation>
<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="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="badRequest">
<element name="badRequest">
<ref name="basicException"/>
</element>
</define>
<define name="internalError">
<element name="internalError">
<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="serviceSubstitution">
<element name="serviceSubstitution">
<ref name="basicException"/>
</element>
</define>
<define name="defaultMappingReturned">
<element name="defaultMappingReturned">
<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="forbidden">
<element name="forbidden">
<ref name="basicException"/>
</element>
</define>
<define name="notFound">
<element name="notFound">
<ref name="basicException"/>
<define name="notFound">
<element name="notFound">
<ref name="basicException"/>
</element>
</define>
</element>
</define>
<define name="loop">
<element name="loop">
<ref name="basicException"/>
</element>
</define>
<define name="loop">
<element name="loop">
<ref name="basicException"/>
</element>
</define>
<define name="serviceNotImplemented">
<element name="serviceNotImplemented">
<ref name="basicException"/>
</element>
</define>
<define name="serviceNotImplemented">
<element name="serviceNotImplemented">
<ref name="basicException"/>
</element>
</define>
<define name="serverTimeout">
<element name="serverTimeout">
<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="serverError">
<element name="serverError">
<ref name="basicException"/>
</element>
</define>
<define name="locationInvalid">
<element name="locationInvalid">
<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="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>
<define name="locationProfileUnrecognized">
<element name="locationProfileUnrecognized">
<attribute name="unsupportedProfiles">
<data type="NMTOKENS"/>
</attribute>
<ref name="basicException"/>
</element>
</define>
</div>
<div>
<a:documentation>
Redirect.
</a:documentation>
<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>
<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>
<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="message">
<optional>
<group>
<attribute name="message">
<data type="token"/>
</attribute>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</group>
</optional>
</define>
<define name="service">
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
</define>
<define name="service">
<optional>
<element name="service">
<data type="anyURI"/>
</element>
</optional>
</define>
<define name="appUniqueString">
<data type="token">
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
</data>
</define>
<define name="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="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>
<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>
<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="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>
<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>
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>
<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>
</grammar>
Figure 21
图21
The XML examples and Relax NG schemas may be found online [24].
XML示例和RELAXNG模式可以在线找到[24]。
Authors' Addresses
作者地址
Ted Hardie Qualcomm, Inc.
泰德·哈迪高通公司。
EMail: hardie@qualcomm.com
EMail: hardie@qualcomm.com
Andrew Newton American Registry for Internet Numbers 3635 Concorde Parkway, Suite 200 Chantilly, VA 20151 US
安德鲁·牛顿美国注册处，互联网编号3635协和公园路，200号套房，弗吉尼亚州尚蒂利，美国20151
Phone: +1 703 227 9894
EMail: andy@hxr.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
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
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
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.priv.at
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.