Network Working Group H. Schulzrinne
Request for Comments: 5582 Columbia U.
Category: Informational September 2009
Network Working Group H. Schulzrinne
Request for Comments: 5582 Columbia U.
Category: Informational September 2009
Location-to-URL Mapping Architecture and Framework
位置到URL映射体系结构和框架
Abstract
摘要
This document describes an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service Translation (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS.
本文档描述了一个全局、可扩展、弹性和管理分布式系统的体系结构，该系统使用位置到服务转换（LoST）协议将地理位置信息映射到URL。该体系结构概括了DNS等分层查找系统中的著名方法。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 4
4.1. The Principal Components . . . . . . . . . . . . . . . . . 4
4.2. Minimal System Architecture . . . . . . . . . . . . . . . 6
5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8
7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10
7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11
7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11
8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of Architecture . . . . . . . . . . . . . . . . . . . 4
4.1. The Principal Components . . . . . . . . . . . . . . . . . 4
4.2. Minimal System Architecture . . . . . . . . . . . . . . . 6
5. Seeker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Trees: Maintaining Authoritative Knowledge . . . . . . . . . . 8
7.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 8
7.2. Answering Queries . . . . . . . . . . . . . . . . . . . . 10
7.3. Overlapping Coverage Regions . . . . . . . . . . . . . . . 11
7.4. Scaling and Reliability . . . . . . . . . . . . . . . . . 11
8. Forest Guides . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Configuring Service Numbers . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
It is often desirable to allow users to access a service that provides a common function but that is actually offered by a variety of local service providers. In many of these cases, the service provider chosen depends on the location of the person wishing to access that service. Among the best-known public services of this kind is emergency calling, where emergency calls are routed to the most appropriate public safety answering point (PSAP) based on the caller's physical location. Other services, from food delivery to directory services and roadside assistance, also follow this general pattern. This is a mapping problem [RFC5012], where a geographic location and a service identifier [RFC5031] is translated into a set of URIs, the service URIs, that allow the Internet system to contact an appropriate network entity that provides the service.
通常希望允许用户访问提供公共功能但实际上由各种本地服务提供商提供的服务。在许多情况下，选择的服务提供商取决于希望访问该服务的人员的位置。这类最著名的公共服务是紧急呼叫，紧急呼叫根据呼叫者的实际位置路由到最合适的公共安全应答点（PSAP）。其他服务，从食品配送到目录服务和路边援助，也遵循这一一般模式。这是一个映射问题[RFC5012]，其中地理位置和服务标识符[RFC5031]被转换为一组URI，即服务URI，允许Internet系统联系提供服务的适当网络实体。
The caller does not need to know from where the service is being provided, and the location of the service provider may change over time, e.g., to deal with temporary overloads, failures in the primary service provider location, or long-term changes in system architecture. For emergency services, this problem is described in more detail in [ECRIT-FRAME].
调用者不需要知道从何处提供服务，并且服务提供者的位置可能随时间而改变，例如，为了处理临时过载、主服务提供者位置中的故障或系统架构中的长期变化。对于紧急服务，此问题在[ECRIT-FRAME]中有更详细的描述。
The overall emergency calling architecture [ECRIT-FRAME] separates mapping from placing calls or otherwise invoking the service, so the same mechanism can be used to verify that a mapping exists ("address validation") or to obtain test service URIs.
整体紧急调用体系结构[ECRIT-FRAME]将映射与放置调用或以其他方式调用服务分离，因此可以使用相同的机制来验证映射是否存在（“地址验证”）或获取测试服务URI。
Mapping locations to URIs that describe services requires a distributed, scalable, and highly resilient infrastructure. Authoritative knowledge about such mappings is distributed among a large number of autonomous entities that may have no direct knowledge of each other. In this document, we describe an architecture for such a global service. It allows significant freedom to combine and split functionality among actual servers and imposes few requirements as to who should operate particular services.
将位置映射到描述服务的URI需要一个分布式、可扩展和高弹性的基础架构。关于这种映射的权威知识分布在大量相互之间可能没有直接知识的自治实体之间。在本文档中，我们描述了这种全局服务的体系结构。它允许在实际服务器之间自由组合和拆分功能，并且对谁应该操作特定服务的要求很少。
Besides determining the service URI, end systems also need to determine the local service numbers. As discussed in Section 9, the architecture described here can also address that problem.
除了确定服务URI之外，终端系统还需要确定本地服务编号。正如第9节所讨论的，这里描述的体系结构也可以解决这个问题。
The architecture described here uses the Location-to-Service Translation (LoST) [RFC5222] protocol, although much of the discussion would also apply for other mapping protocols satisfying the mapping requirements [RFC5012].
此处描述的体系结构使用位置到服务转换（LoST）[RFC5222]协议，尽管大部分讨论也适用于满足映射要求的其他映射协议[RFC5012]。
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 RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
In addition to the terms defined in [RFC5012], this document uses the following terms to describe LoST clients and servers:
除[RFC5012]中定义的术语外，本文件还使用以下术语描述丢失的客户端和服务器：
authoritative mapping server (AMS): An authoritative mapping server (AMS) is a LoST server that can provide the authoritative answer to a particular set of queries, e.g., covering a set of Presence Information Data Information Location Object (PIDF-LO) civic labels or a particular region described by a geometric shape. In some (rare) cases of territorial disputes, two resolvers may be authoritative for the same region. An AMS may redirect or forward a query to another AMS within the tree.
权威映射服务器（AMS）：权威映射服务器（AMS）是一个丢失的服务器，可以为一组特定的查询提供权威答案，例如，覆盖一组状态信息数据位置对象（PIDF-LO）公民标签或由几何形状描述的特定区域。在某些（罕见的）领土争端案例中，两名解决者可能对同一地区具有权威性。AMS可以将查询重定向或转发到树中的另一个AMS。
child: A child is an AMS that is authoritative for a subregion of another AMS. A child can in turn be parent for another AMS.
子级：子级是对另一个AMS的子区域具有权威性的AMS。一个孩子可以反过来成为另一个AMS的父母。
(tree node) cluster: A node cluster is a group of LoST servers that all share the same mapping information and return the same results for queries. Clusters provide redundancy and share query load. Clusters are fully-meshed, i.e., they all exchange updates with each other.
（树节点）群集：节点群集是一组丢失的服务器，它们共享相同的映射信息并返回相同的查询结果。集群提供冗余并共享查询负载。集群是完全网格化的，即它们都相互交换更新。
coverage region: The coverage region of an AMS is the geographic region within which the AMS is able to authoritatively answer mapping queries. Coverage regions are generally, but not necessarily, contiguous and may be represented as either a subset of a civic address or a geometric object.
覆盖区域：AMS的覆盖区域是AMS能够权威地回答映射查询的地理区域。覆盖区域通常（但不一定）是连续的，并且可以表示为公民地址的子集或几何对象。
forest guide (FG): A forest guide (FG) has knowledge of the coverage region of trees for a particular top-level service.
森林指南（FG）：森林指南（FG）了解特定顶级服务的树木覆盖区域。
mapping: A mapping is a short-hand for 'mapping from a location object to either another mapping server or the desired service URLs'.
映射：映射是“从一个位置对象映射到另一个映射服务器或所需的服务URL”的缩写。
parent: A mapping server that covers the region of all of its children. A mapping server without a parent is a root AMS.
父级：覆盖其所有子级区域的映射服务器。没有父级的映射服务器是根AMS。
resolver: A resolver is contacted by a seeker, consults a forest mapping server, and then resolves the query using an appropriate tree. Resolvers may cache query results.
解析程序：搜索者联系解析程序，咨询林映射服务器，然后使用适当的树解析查询。解析程序可以缓存查询结果。
seeker: A seeker is a LoST client requesting a mapping. A seeker does not provide mapping services to others but may cache results for its own use.
导引头：导引头是请求映射的丢失客户端。导引头不向其他人提供映射服务，但可以缓存结果供自己使用。
tree: A tree consists of a self-contained hierarchy of authoritative mapping servers for a particular service. Each tree exports its coverage region to the forest mapping servers.
树：树由特定服务的权威映射服务器的自包含层次结构组成。每个树都将其覆盖区域导出到林映射服务器。
The mapping architecture distinguishes four logical roles: seekers, resolvers, authoritative mapping servers (AMS), and forest guides (FGs). End users of the LoST-based [RFC5222] mapping mechanism, called seekers, contact resolvers that cache query results and know one or more forest guides. Forest guides form the top level of a conceptual hierarchy, with one or more trees providing a hierarchical resolution service for different geographic regions. Forest guides know the geographic coverage region of all or almost all trees and direct queries to the node at the top of the appropriate tree. Trees
映射体系结构区分了四个逻辑角色：搜索者、解析者、权威映射服务器（AMS）和林指南（FGs）。基于LoST的[RFC5222]映射机制（称为搜索者）的最终用户与缓存查询结果并了解一个或多个林指南的解析程序联系。森林指南构成概念层次的顶层，一棵或多棵树为不同的地理区域提供层次解析服务。森林向导知道所有或几乎所有树的地理覆盖区域，并将查询直接指向相应树顶部的节点。树
consist of authoritative mapping servers and maintain the authoritative mapping information.
由权威映射服务器组成，并维护权威映射信息。
Seekers, resolvers, authoritative mapping servers, and forest guides all communicate using LoST; indeed, it is likely that, in many cases, the same software can operate as a resolver, authoritative mapping server, and forest guide. In addition to the basic LoST query protocol [RFC5222], a synchronization protocol [LOST-SYNC] may be used to exchange information between forest guides or to push coverage information from a tree node to its parent.
搜索者、解析器、权威映射服务器和森林向导都使用LoST进行通信；事实上，在许多情况下，同一软件可能可以作为解析器、权威映射服务器和林指南运行。除基本丢失查询协议[RFC5222]外，同步协议[LoST-SYNC]还可用于在林指南之间交换信息，或将覆盖率信息从树节点推送到其父节点。
Seekers may be part of Voice over IP (VoIP) or other end systems, or of SIP proxies or similar call routing functions.
搜索者可能是IP语音（VoIP）或其他终端系统的一部分，或SIP代理或类似呼叫路由功能的一部分。
Figure 1 shows the interaction of the components. The lines indicating the connection between the forest guides are logical connections, indicating that they are synchronizing their information via the synchronization protocol [LOST-SYNC].
图1显示了组件之间的交互。指示林指南之间连接的行是逻辑连接，表示它们正在通过同步协议[LOST-SYNC]同步其信息。
/-\ /-\ +-----+ +-----+
| S +******* R ********* FG *-----------------+ FG |
\-/ \-/ | |* | |
+--+--+ * +--+--+
| * |
| * |
| * |
| * |
/-\ +--+--+ * +--+--+
| R +------>+ FG +-----*-----------+ FG |
\-/ | | * | |
+--+--+ * +--+--+
| * |
| * |
| * |
|*** ^
/ \ / \
/ \ / \
/ \ / \
/ \ / \
----------- -----------
tree tree
/-\ /-\ +-----+ +-----+
| S +******* R ********* FG *-----------------+ FG |
\-/ \-/ | |* | |
+--+--+ * +--+--+
| * |
| * |
| * |
| * |
/-\ +--+--+ * +--+--+
| R +------>+ FG +-----*-----------+ FG |
\-/ | | * | |
+--+--+ * +--+--+
| * |
| * |
| * |
|*** ^
/ \ / \
/ \ / \
/ \ / \
/ \ / \
----------- -----------
tree tree
Architecture diagram, showing seekers (S), resolvers (R), forest guides (FG), and trees. The star (*) line indicates the flow of the query and responses in recursive mode, while the lines indicate synchronization relationships.
架构图，显示导引头（S）、解析器（R）、林向导（FG）和树。星形（*）行表示递归模式下的查询和响应流，而这些行表示同步关系。
Figure 1
图1
The mapping function for the world is divided among trees. The collection of trees may not cover the whole world, and trees are added and removed as the organization of mapping data changes. We call the collection of trees a forest. There is no limit on the number of trees within the forest, but the author guesses that the number of trees will likely be somewhere between a few hundred and a few thousand. The lower estimate would apply if each country operates one tree, the higher if different governmental or private organizations within a country operate independent trees. We assume that tree coverage information changes relatively slowly, on the order of less than one change per year per tree, although the system imposes no specific threshold. Tree coverage would change, for example, if a country is split or merged or if two trees for different regions become part of a larger tree. (On the other hand, information within a tree is likely to change much more frequently.)
世界的映射功能在树之间划分。树的集合可能不会覆盖整个世界，随着映射数据组织的更改，会添加和删除树。我们把收集的树木称为森林。森林中的树木数量没有限制，但作者猜测树木数量可能在几百到几千之间。如果每个国家经营一棵树，则适用较低的估计数；如果一个国家内的不同政府或私人组织经营独立的树，则适用较高的估计数。我们假设树木覆盖率信息变化相对缓慢，每棵树每年变化不到一次，尽管系统没有规定具体的阈值。例如，如果一个国家被分割或合并，或者如果不同地区的两棵树成为一棵大树的一部分，树木覆盖率就会发生变化。（另一方面，树中的信息可能会更频繁地更改。）
It is possible to build a functioning system consisting only of seekers and resolvers if these resolvers have other means of obtaining mapping data. For example, a company acting as a mapping service provider could collect mapping records manually and make them available to their customers through the resolver. While feasible as a starting point, such an architecture is unlikely to scale globally. Among other problems, it becomes very hard for providers of authoritative data to ensure that all such providers have up-to-date information. If new trees are set up, they would somehow make themselves known to these providers. Such a mechanism would be similar to the old "hosts.txt" mechanism for distributing host information in the early Internet before DNS was developed.
如果搜索器和解析器具有获取映射数据的其他方法，则可以构建仅由搜索器和解析器组成的功能系统。例如，作为映射服务提供商的公司可以手动收集映射记录，并通过解析器将其提供给客户。虽然作为一个起点是可行的，但这样的体系结构不太可能在全球范围内扩展。除其他问题外，权威数据提供商很难确保所有此类提供商都拥有最新信息。如果建立新的树，它们会以某种方式让这些提供者知道它们自己。这种机制类似于早期DNS开发之前用于在Internet上分发主机信息的旧“hosts.txt”机制。
Below, we describe the operation of each component in more detail.
下面，我们将更详细地描述每个组件的操作。
Clients desiring location-to-service mappings are known as seekers. Seekers are consumers of mapping data and originate LoST queries as LoST protocol clients. Seekers do not answer LoST queries. They contact either forest guides or resolvers to find the appropriate tree that can authoritatively answer their questions. Seekers can be end systems such as SIP user agents, or call routing entities such as SIP proxy servers.
需要位置到服务映射的客户端称为搜索者。搜索者是映射数据的消费者，并作为丢失的协议客户端发起丢失的查询。搜索者不会回答丢失的查询。他们联系林向导或解析者，以找到能够权威地回答他们问题的适当树。搜索者可以是终端系统（如SIP用户代理），也可以是呼叫路由实体（如SIP代理服务器）。
Seekers may need to obtain mapping information in several steps, i.e., they may obtain pointers to intermediate servers that lead them closer to the final mapping. Seekers MAY cache query results for later use but otherwise have no obligations to other entities in the system.
搜索者可能需要通过几个步骤获得映射信息，即，他们可能获得指向中间服务器的指针，从而使他们更接近最终映射。搜索者可以缓存查询结果供以后使用，但对系统中的其他实体没有义务。
Seekers need to be able to identify appropriate resolvers. The mechanism for providing seekers with that information is likely to differ depending on who operates the resolvers. For example, if the voice service provider operates the resolver, it might include the location of the resolver in the SIP configuration information it distributes to its user agents. An Internet access provider or enterprise can provide a pointer to a resolver via DHCP [RFC5223]. In an ad hoc or zero-configuration environment, appropriate service directories may advertise resolvers.
搜索者需要能够识别适当的解析器。为搜索者提供该信息的机制可能会因操作解析器的人而异。例如，如果语音服务提供商操作冲突解决程序，它可能会在分发给其用户代理的SIP配置信息中包含冲突解决程序的位置。Internet访问提供商或企业可以通过DHCP[RFC5223]提供指向解析器的指针。在特殊或零配置环境中，适当的服务目录可能会公布解析程序。
Like other entities in the system, seekers can cache responses. This is particularly useful if the response describes the result for a civic or geospatial region, rather than just a point. For example, for mobile nodes, seekers would only have to update their resolution results when they leave the coverage area of a service provider, such as a PSAP for emergency services, and can avoid repeatedly polling for this information whenever the location information changes slightly. (Mobile nodes would also need a location update mechanism that is either local or triggered when they leave the current service area.) This will likely be of particular benefit for seekers representing a large user population, such as the outbound proxy in a corporate network. For example, rather than having to query separately for each cubicle, information provided by the authoritative node may indicate that the whole campus is covered by the same service provider.
与系统中的其他实体一样，搜索者可以缓存响应。如果响应描述的是城市或地理空间区域的结果，而不仅仅是一个点，则这一点尤其有用。例如，对于移动节点，搜索者只需在离开服务提供商（如紧急服务的PSAP）的覆盖区域时更新其解析结果，并且可以避免在位置信息发生轻微变化时重复轮询该信息。（移动节点还需要一个位置更新机制，该机制可以是本地的，也可以在它们离开当前服务区域时触发。）这可能对代表大量用户群体的搜索者（例如公司网络中的出站代理）特别有利。例如，权威节点提供的信息可以指示整个校园由同一服务提供商覆盖，而不必单独查询每个隔间。
Given this caching mechanism and cache lifetimes of several days, most mobile users traveling to and from work would only need to obtain service area information along their commute route once during each cache lifetime.
考虑到这种缓存机制和几天的缓存生存期，大多数上下班的移动用户在每个缓存生存期内只需沿其通勤路线获取一次服务区域信息。
A seeker can contact a forest guide (see below) directly, but may not be able to easily locate such a guide. In addition, seekers in the same geographic area may already have asked the same question. Thus, it makes sense to introduce another entity, known as a resolver in the architecture, that knows how to contact one or more forest guides and that caches earlier queries to accelerate the response to mapping queries and to improve the resiliency of the system. Each resolver can decide autonomously which FGs to use, with possibly different choices for each top-level service.
导引头可以直接联系森林向导（见下文），但可能无法轻松找到此类向导。此外，在同一地理区域的求职者可能已经问过同样的问题。因此，引入另一个实体（在体系结构中称为解析器）是有意义的，该实体知道如何联系一个或多个林指南，并缓存早期查询，以加速对映射查询的响应，并提高系统的弹性。每个解析器可以自主决定使用哪个FGs，每个顶级服务可能有不同的选择。
ISPs or Voice Service Providers (VSPs) may include the address of a suitable resolver in their configuration information, e.g., in SIP configuration for a VSP or DHCP [RFC5223] for an ISP. Resolvers are manually configured with the name of one or more forest guides.
ISP或语音服务提供商（VSP）可以在其配置信息中包括合适的解析器的地址，例如，在VSP的SIP配置中或ISP的DHCP[RFC5223]中。使用一个或多个林指南的名称手动配置解析程序。
The architecture assumes that authoritative knowledge about the mapping data is distributed among many independent administrative entities, but clients (seekers) may potentially need to find out mapping information for any spot on earth. (Extensions to extra-terrestrial applications are left for future exploration.) Information is organized hierarchically, in a tree, with tree nodes representing larger geographic areas pointing to several child nodes, each representing a smaller area. Each tree node can be a cluster of LoST servers that all contain the same information and back up each other.
该体系结构假设有关地图数据的权威知识分布在许多独立的管理实体之间，但客户（搜索者）可能需要查找地球上任何地点的地图信息。（对外星应用程序的扩展留给未来的探索。）信息在树中分层组织，树节点表示更大的地理区域，指向几个子节点，每个子节点表示更小的区域。每个树节点可以是一个丢失的服务器集群，这些服务器都包含相同的信息并相互备份。
Each tree can map a location described by either civic or geographic coordinates, but not both, for one type of service (such as 'sos.police', 'sos.fire' or 'counseling') and one location profile, although nothing prevents re-using the same servers for multiple, different services or both types of coordinates. The collection of all trees for one service and location profile is known as a forest.
每个树都可以映射一种服务类型（如“sos.警察”、“sos.消防”或“咨询”）和一个位置配置文件的公民或地理坐标描述的位置，但不能同时映射两者，尽管没有任何东西阻止对多个不同服务或两种坐标类型重复使用相同的服务器。一个服务和位置配置文件的所有树的集合称为林。
Each tree root announces its coverage region to one or more forest guides.
每个树根向一个或多个森林向导宣布其覆盖区域。
Each tree node cluster knows the coverage region of its children and sends queries to the appropriate server "down" the tree. Each such tree node knows authoritatively about the service mappings for a particular region, typically, but not necessarily, contiguous. The region can be described by any of the shapes in the LoST specification expressed in geospatial coordinates, such as circles or polygons, or a set of civic address descriptors (e.g., "country = DE, A1 = Bavaria"). These coverage regions may be aligned with political boundaries, but that is not required. In most cases, to avoid confusion, only one cluster is responsible for a particular geographic or civic location, but the system can also deal with cases where coverage regions overlap.
每个树节点集群都知道其子节点的覆盖区域，并将查询发送到树下相应的服务器。每个这样的树节点都权威地知道特定区域的服务映射，通常（但不一定）是连续的。该区域可由丢失规范中以地理空间坐标表示的任何形状来描述，例如圆或多边形，或一组公民地址描述符（例如，“country=DE，A1=Bavaria”）。这些覆盖区域可能与政治边界保持一致，但这不是必需的。在大多数情况下，为了避免混淆，只有一个集群负责特定的地理或城市位置，但系统也可以处理覆盖区域重叠的情况。
There are no assumptions about the coverage region of a tree as a whole. For example, a tree could cover a single city, a state/ province, or a whole country. Nodes within a tree need to loosely coordinate their operation, but they do not need to be operated by the same administrator.
没有关于树作为一个整体的覆盖区域的假设。例如，一棵树可以覆盖一个城市、一个州/省或整个国家。树中的节点需要松散地协调它们的操作，但它们不需要由同一个管理员操作。
The tree architecture is roughly similar to the domain name system (DNS), except that delegation is not by label but rather by region. (Naturally, DNS does not have the notion of forest guides.) One can
树结构与域名系统（DNS）大致相似，不同之处在于授权不是按标签而是按区域。（当然，DNS没有森林指南的概念。）可以
also draw analogies to the Lightweight Directory Access Protocol (LDAP) when deployed in a distributed fashion.
当以分布式方式部署时，还可以与轻量级目录访问协议（LDAP）进行类比。
Tree nodes maintain two types of information -- namely, coverage regions and mappings. Coverage regions describe the region served by a child node in the tree and point to a child node for further resolution. Mappings contain an actual service URI leading to a service provider or another signaling server representing a group of service providers, which in turn might further route signaling requests to more servers covering smaller regions.
树节点维护两种类型的信息——即覆盖区域和映射。覆盖区域描述树中的子节点所服务的区域，并指向子节点以进一步解析。映射包含一个实际的服务URI，该URI指向一个服务提供者或另一个表示一组服务提供者的信令服务器，这又可能进一步将信令请求路由到覆盖较小区域的更多服务器。
Leaf nodes, i.e., nodes without children, only maintain mappings, while tree nodes above the leaf nodes only maintain coverage regions. An example for emergency services of a leaf node entry is shown below, indicating how queries for three towns are directed to different PSAPs. Queries for Englewood are directed to another LoST server instead.
叶节点（即没有子节点的节点）仅维护映射，而叶节点上方的树节点仅维护覆盖区域。下面显示了叶节点条目的紧急服务示例，说明了如何将三个城镇的查询定向到不同的PSAP。对Englewood的查询被定向到另一台丢失的服务器。
country A1 A2 A3 resource or LoST server
US NJ Bergen Leonia sip:psap@leonianj.gov
US NJ Bergen Fort Lee sip:emergency@fortleenj.org
US NJ Bergen Teaneck sip:police@teanecknjgov.org
US NJ Bergen Englewood englewoodnj.gov
....
country A1 A2 A3 resource or LoST server
US NJ Bergen Leonia sip:psap@leonianj.gov
US NJ Bergen Fort Lee sip:emergency@fortleenj.org
US NJ Bergen Teaneck sip:police@teanecknjgov.org
US NJ Bergen Englewood englewoodnj.gov
....
Coverage regions are described by sets of LoST-compatible shapes enclosing contiguous geographic areas or by descriptors enumerating groups of civic locations. For the former, the LoST server performs the same matching operation as described in Section 12.2 of the LoST specification [RFC5222] to find the tree or AMS.
覆盖区域由包围连续地理区域的丢失兼容形状集或枚举城市位置组的描述符来描述。对于前者，丢失服务器执行与丢失规范[RFC5222]第12.2节所述相同的匹配操作，以查找树或AMS。
As a civic location example, a state-level tree node for New Jersey in the United States may contain the coverage region entries shown below, indicating that any query matching a location in Bergen County, for example, would be redirected or forwarded to the node located at bergen.nj.example.org.
作为公民位置示例，美国新泽西州的州级树节点可能包含如下所示的覆盖区域条目，这表明任何匹配卑尔根县位置的查询都将被重定向或转发到位于Bergen.nj.example.org的节点。
There is no requirement that all child nodes cover the same level within the civic hierarchy. As an example, in the table below, the city of Newark has decided to be listed directly within the state node, rather than through the county. Longest-match rules allow partial coverage so that queries for all other towns within Essex county would be directed to the county node for further resolution.
不要求所有子节点都覆盖civic层次结构中的同一级别。例如，在下表中，纽瓦克市决定直接列在州节点内，而不是通过县。最长匹配规则允许部分覆盖，因此对埃塞克斯县内所有其他城镇的查询将被定向到县节点进行进一步解析。
C A1 A2 A3 LoST server name
US NJ Atlantic * atlantic.nj.example.org/sos
US NJ Bergen * bergen.nj.example.org/sos
US NJ Monmouth * monmouth.nj.example.org/sos
US NJ Essex * essex.nj.example.org/sos
US NJ Essex Newark newark.example.com/sos
....
C A1 A2 A3 LoST server name
US NJ Atlantic * atlantic.nj.example.org/sos
US NJ Bergen * bergen.nj.example.org/sos
US NJ Monmouth * monmouth.nj.example.org/sos
US NJ Essex * essex.nj.example.org/sos
US NJ Essex Newark newark.example.com/sos
....
Thus, there is no substantial difference between coverage region and mapping data. The only difference is that coverage regions return names of LoST servers, while mapping entries contain service URLs. Mapping entries may be specific down to the house- or floor-level or may only contain street-level information. For example, in the United States, civic mapping data for emergency services is generally limited to address ranges ("MSAG data"), so initial mapping databases may only contain street-level information.
因此，覆盖区域和地图数据之间没有实质性差异。唯一的区别是覆盖区域返回丢失服务器的名称，而映射条目包含服务URL。映射条目可以具体到房屋或楼层，也可以仅包含街道级别的信息。例如，在美国，应急服务的公民地图数据通常限于地址范围（“MSAG数据”），因此初始地图数据库可能只包含街道级别的信息。
To automate the maintenance of trees, the LoST synchronization mechanism [LOST-SYNC] allows nodes to query other nodes for mapping data and coverage regions, both within a cluster and across different hierarchy levels in a tree. In the example above, the state-run node would query the county nodes and use the records returned to distribute incoming LoST queries to the county nodes. Conversely, nodes could also contact their parent nodes to tell them about their coverage region. There is some benefit of child nodes contacting their parents, as this allows changes in coverage regions to propagate quickly up the tree.
为了自动化树的维护，丢失同步机制[LoST-SYNC]允许节点查询其他节点，以在集群内和树的不同层次上映射数据和覆盖区域。在上面的示例中，国营节点将查询县节点，并使用返回的记录将传入的丢失查询分发到县节点。相反，节点也可以联系其父节点，告诉他们其覆盖区域。子节点与其父节点联系有一些好处，因为这允许覆盖区域中的更改在树上快速传播。
Within a tree, the basic operation is straightforward. A query reaches the root of the tree. That node determines which coverage region matches that request and forwards the request to the server indicated in the coverage region record, returning a response to the querier when it in turn receives an answer (recursion). Alternatively, the node returns the application unique string (server name) of that child node to the querier (iteration). This process applies to each node, i.e., a node does not need to know whether the original query came from a parent node, a seeker, a forest guide, or a resolver.
在树中，基本操作非常简单。查询到达树的根。该节点确定哪个覆盖区域与该请求相匹配，并将请求转发到覆盖区域记录中指示的服务器，当查询器依次收到响应（递归）时，将响应返回给查询器。或者，该节点将该子节点的应用程序唯一字符串（服务器名称）返回给查询器（迭代）。此过程适用于每个节点，即，节点不需要知道原始查询是来自父节点、搜索者、林指南还是解析程序。
For efficiency, a node MAY return region information instead of a point answer. Thus, instead of returning that a particular geospatial coordinate maps to a service URL or server name, it MAY return a polygon indicating the region for which this answer would be returned, along with expiration time (time-to-live) information. The querying node can then cache this information for future use.
为了提高效率，节点可以返回区域信息而不是点答案。因此，与返回特定地理空间坐标映射到服务URL或服务器名称不同，它可能返回一个多边形，指示将返回此答案的区域，以及过期时间（生存时间）信息。然后，查询节点可以缓存该信息以供将来使用。
For civic coordinates, trees may not include individual mapping records for each floor, house number, or street. To avoid giving the wrong indication that a particular location has been found valid, LoST can indicate which parts of the location information have actually been used to look up a mapping.
对于Civil坐标，树木可能不包括每个楼层、门牌号或街道的单独地图记录。为了避免错误地指示某个特定位置已被发现有效，LoST可以指示位置信息的哪些部分已实际用于查找映射。
In some cases, coverage regions may overlap, either because there is a dispute as to who handles a particular geographic region or, more likely, because the resolution of the coverage map may not be sufficiently high. For example, a node may "shave some corners" off its polygon so that its coverage region appears to overlap with its geographic neighbor. For civic coordinates, houses on the same street may be served by different PSAPs. The mapping mechanism needs to work even if a coverage map is imprecise or if there are disputes about coverage.
在某些情况下，覆盖区域可能重叠，这可能是因为对谁处理特定地理区域存在争议，或者更可能是因为覆盖地图的分辨率可能不够高。例如，节点可能会从多边形上“剃掉一些角”，使其覆盖区域看起来与其地理邻居重叠。对于城市坐标，同一条街上的房屋可能由不同的PSAP提供服务。即使覆盖率地图不精确或存在覆盖率争议，映射机制也需要工作。
The solution for overlapping coverage regions is relatively simple. If a query matches multiple coverage regions, the node returns all URLs or server names, in redirection mode, or queries both children, if in recursive mode. If the overlapping coverage is caused by imprecise coverage maps, only one will return a result and the others will return an error indication. If the particular location is disputed territory, the response will contain all answers, leaving it to the querier to choose the preferred solution or try to contact all services in turn.
重叠覆盖区域的解决方案相对简单。如果查询匹配多个覆盖区域，则节点将在重定向模式下返回所有URL或服务器名称，或者在递归模式下同时查询两个子节点。如果重叠覆盖是由不精确的覆盖图引起的，则只有一个将返回结果，其他将返回错误指示。如果特定位置是有争议的区域，则响应将包含所有答案，由查询者选择首选解决方案或尝试依次联系所有服务。
Since they provide authoritative information, tree nodes need to be highly reliable. Thus, while this document refers to tree nodes as logical entities within the tree, an actual implementation would likely replicate node information across several servers, forming a cluster. Each such node would have the same information. Standard techniques such as DNS SRV records can be used to select one of the servers. Replication within the cluster can use any suitable protocol mechanism, but a standardized, incremental update mechanism makes it easier to spread those nodes across multiple independently administered locations. The techniques developed for the meshed Service Location Protocol (SLP) [RFC3528] are applicable here.
由于树节点提供权威信息，因此需要高度可靠。因此，虽然本文档将树节点称为树中的逻辑实体，但实际实现可能会跨多个服务器复制节点信息，从而形成一个集群。每个这样的节点将具有相同的信息。可以使用DNS SRV记录等标准技术选择其中一台服务器。集群内的复制可以使用任何合适的协议机制，但标准化的增量更新机制使这些节点更容易分散到多个独立管理的位置。为网状服务定位协议（SLP）[RFC3528]开发的技术适用于此处。
Unfortunately, just having trees covering various regions of the world is not sufficient, as a client of the mapping protocol would not generally be able to keep track of all the trees in the forest. To facilitate orientation among the trees, we introduce a forest
不幸的是，仅仅让树木覆盖世界各地是不够的，因为映射协议的客户端通常无法跟踪森林中的所有树木。为了便于树木之间的定向，我们引入了一个森林
guide (FG), which keeps track of the coverage regions of all the trees for one service and location profile. For scalability and reliability, there will need to be a large number of forest guides, all providing the same information. A seeker can contact a suitable forest guide and will then be directed to the right tree or, rarely, set of trees. Forest guides do not provide mapping information themselves, but rather redirect to mapping servers. In some configurations, not all forest guides may provide the same information, due to policy reasons.
指南（FG），用于跟踪一个服务和位置配置文件的所有树的覆盖区域。为了实现可扩展性和可靠性，需要大量的森林指南，它们都提供相同的信息。探索者可以联系合适的森林向导，然后被引导到正确的树上，或者很少是一组树上。林指南本身不提供映射信息，而是重定向到映射服务器。在某些配置中，由于策略原因，并非所有林指南都提供相同的信息。
Forest guides fulfill a similar role to root servers in DNS. They distribute information, signed for authenticity, offered by trees. However, introducing forest guides avoids creating a global root, with the attendant management and control issues.
林指南在DNS中扮演与根服务器类似的角色。他们分发由树木提供的信息，并签字确认其真实性。然而，引入林指南避免了创建全局根目录，并伴随着管理和控制问题。
However, unlike DNS root servers, forest guides may offer different information based on local policy. Forest guides can also restrict their data synchronization to parts of the information. For example, if country C does not recognize country T, C can propagate tree regions for all but T.
但是，与DNS根服务器不同，林指南可能根据本地策略提供不同的信息。林指南还可以将其数据同步限制为部分信息。例如，如果国家C不识别国家T，则C可以传播除T以外的所有国家的树区域。
For authenticity, the coverage regions SHOULD be digitally signed by the authorities responsible for the region, as discussed in more detail in Section 10. They are used by resolvers and possibly seekers to find the appropriate tree for a particular area. All forest guides should have consistent information, i.e., a collection of all the coverage regions of all the trees. A tree node at the top of a tree can contact any forest guide and inject new coverage region information into the system. One would expect that each tree announces its coverage to more than one forest guide. Each forest guide peers with one or more other guides and distributes new coverage region announcements to other guides. Due to policy and maybe political reasons, not all forest guides may share the same coverage region data.
为确保真实性，覆盖区域应由负责该区域的机构进行数字签名，如第10节所述。解析程序和搜索程序使用它们为特定区域找到合适的树。所有森林指南应具有一致的信息，即所有树木的所有覆盖区域的集合。树顶部的树节点可以联系任何林指南，并将新的覆盖区域信息注入系统。人们会期望每棵树向不止一位森林向导宣布其覆盖范围。每个森林指南与一个或多个其他指南对等，并向其他指南分发新的覆盖区域公告。由于政策和可能的政治原因，并非所有森林指南都可以共享相同的覆盖区域数据。
Forest guides can, in principle, be operated by anybody, including voice service providers, Internet access providers, dedicated services providers, and enterprises.
原则上，森林指南可以由任何人操作，包括语音服务提供商、互联网接入提供商、专用服务提供商和企业。
As in routing, peering with other forest guides implies a certain amount of trust in the peer. Thus, peering is likely to require some negotiation between the administering parties concerned, rather than automatic configuration. The mechanism itself does not imply a particular policy as to who gets to advertise a particular coverage region.
与路由一样，使用其他林向导进行对等意味着对对等方有一定程度的信任。因此，对等可能需要相关管理方之间进行一些协商，而不是自动配置。该机制本身并不意味着对谁可以为特定的覆盖区域做广告有特定的政策。
The section below is not directly related to the problem of determining service location but is an instance of the more generic problem solved by this architecture -- namely, mapping location information to service-related parameters, such as service numbers.
下面的部分与确定服务位置的问题没有直接关系，而是此体系结构解决的更一般问题的一个实例，即，将位置信息映射到服务相关参数，如服务编号。
For the foreseeable future, some user devices and software will emulate the user interface of a telephone, i.e., the only way to enter call address information is via a 12-button keypad with digits and the asterisk and hash symbols. These devices use service numbers to identify services. The best-known examples of service numbers are emergency numbers, such as 9-1-1 in North America and 1-1-2 in Europe. However, many other public and private service numbers have been defined, ranging in the United States from 3-1-1 for non-emergency local government services to 4-1-1 for directory assistance, to various "800" numbers for anything from roadside assistance to legal services to home-delivery food.
在可预见的未来，一些用户设备和软件将模拟电话的用户界面，即，输入呼叫地址信息的唯一方法是通过带有数字、星号和哈希符号的12键键盘。这些设备使用服务编号来标识服务。最著名的服务号码示例是紧急号码，如北美的9-1-1和欧洲的1-1-2。然而，许多其他公共和私人服务编号已被定义，在美国范围从非紧急地方政府服务的3-1-1到目录援助的4-1-1，再到从路边援助到法律服务到送货上门食品的各种“800”编号。
Such service numbers are likely to be used until essentially all communication devices feature IP connectivity and an alphanumeric keyboard. Unfortunately, for emergency services, more than 60 emergency numbers are in use throughout the world, with many of those numbers serving non-emergency purposes elsewhere, e.g., identifying repair or directory services. Countries also occasionally change their emergency numbers to conform to regional agreements. An example is the introduction of "1-1-2" for countries in Europe.
在基本上所有通信设备都具有IP连接和字母数字键盘之前，可能会使用此类服务号码。不幸的是，在紧急服务方面，全世界使用了60多个紧急号码，其中许多号码在其他地方用于非紧急用途，例如识别维修或目录服务。各国偶尔也会根据区域协议更改紧急号码。一个例子是为欧洲国家引入“1-1-2”。
Thus, a system that allows devices to be used internationally to place calls needs to allow devices to discover service numbers automatically. In the Internet-based system proposed in [ECRIT-FRAME], these numbers are strictly used as a human-user interface mechanism and are generally not visible in call signaling messages, which carry the service URN [RFC5031] instead.
因此，允许设备在国际上进行呼叫的系统需要允许设备自动发现服务号码。在[ECRIT-FRAME]中提出的基于互联网的系统中，这些数字严格用作人机界面机制，通常在呼叫信令消息中不可见，而这些消息携带服务URN[RFC5031]。
For the best user experience, systems should be able to discover two sets of service numbers -- namely, those used in the user's home country and those used in the country the user is currently visiting. The user is most likely to remember the former, but a companion borrowing a device in an emergency, say, may only know the local emergency numbers.
为了获得最佳的用户体验，系统应该能够发现两组服务号码——即用户所在国使用的号码和用户当前访问的国家使用的号码。用户最有可能记住前者，但在紧急情况下借用设备的同伴可能只知道当地的紧急号码。
Determining home and local service numbers is a configuration problem, but unfortunately, existing configuration mechanisms are ill-suited for this purpose. For example, a DHCP server might be able to provide the local service numbers but not the home numbers. When virtual private networks (VPNs) are used, even DHCP may provide numbers of uncertain origin, as a user may contact the home network
确定家庭和本地服务号码是一个配置问题，但不幸的是，现有的配置机制不适合此目的。例如，DHCP服务器可能能够提供本地服务号码，但不能提供家庭号码。当使用虚拟专用网络（VPN）时，即使DHCP也可能提供来源不确定的号码，因为用户可能会联系家庭网络
or some local branch office of the corporate network. Similarly, SIP configuration [CONFIG-FRAME] would be able to provide the numbers valid at the location of the SIP service provider, but even a SIP service provider with a national footprint may serve customers that are visiting any number of other countries.
或者公司网络的某个本地分支机构。类似地，SIP配置[CONFIG-FRAME]将能够提供SIP服务提供商所在地的有效号码，但即使是具有国家足迹的SIP服务提供商也可以为访问任何数量的其他国家的客户提供服务。
Also, while initially there are likely to be only a few service numbers, e.g., for emergency services, the LoST architecture can be used to support other services, as noted. Configuring every local DHCP or SIP configuration server with that information is likely to be error-prone and tedious.
此外，虽然最初可能只有几个服务编号，例如紧急服务，但如前所述，丢失的体系结构可用于支持其他服务。用这些信息配置每个本地DHCP或SIP配置服务器很可能容易出错，而且很繁琐。
For these reasons, the LoST-based mapping architecture supports providing service numbers to end systems based on caller location. The mapping operation is almost exactly the same as for determining the service URL. The mapping can be obtained along with the service URL. The major difference between the two requests is that service numbers often have much larger regions of validity than the service URL itself. Also, the service number is likely to be valid longer than the service URL. Finally, an end system may want to look up the service number for its home location, not just its current (visited) location.
由于这些原因，基于丢失的映射体系结构支持基于呼叫者位置向终端系统提供服务号码。映射操作几乎与确定服务URL的操作完全相同。映射可以与服务URL一起获得。这两个请求之间的主要区别在于，服务编号的有效区域通常比服务URL本身大得多。此外，服务编号的有效期可能长于服务URL。最后，终端系统可能希望查找其主位置的服务编号，而不仅仅是其当前（访问）位置。
Security considerations for emergency services mapping are discussed in [RFC5069], while [RFC5031] discusses issues related to the service URN, one of the inputs into the mapping protocol. LoST-related security considerations are naturally discussed in the LoST specification [RFC5222].
[RFC5069]讨论了应急服务映射的安全注意事项，而[RFC5031]讨论了与服务URN（映射协议的输入之一）相关的问题。丢失规范[RFC5222]中自然讨论了丢失相关的安全注意事项。
The architecture addresses the following security issues, usually through the underlying transport security associations:
该体系结构通常通过底层传输安全关联解决以下安全问题：
server impersonation: Seekers, resolvers, fellow tree guides, and cluster members can assure themselves of the identity of the remote party by using the facilities in the underlying channel security mechanism, such as Transport Layer Security (TLS) [RFC5246].
服务器模拟：搜索者、解析者、同伴树向导和集群成员可以通过使用底层通道安全机制中的设施（如传输层安全（TLS）[RFC5246]）来确保远程方的身份。
query or query result corruption: To avoid the possibility of an attacker modifying the query or its result, the architecture RECOMMENDS the use of channel security, such as TLS. Results SHOULD also be digitally signed, e.g., using XML digital signatures [W3C.REC-xmldsig-core-20020212]. Note, however, that simple origin assertion may not provide the end system with enough useful information as it has no good way of knowing that a particular signer is authorized to represent a particular
查询或查询结果损坏：为避免攻击者修改查询或其结果的可能性，体系结构建议使用通道安全性，如TLS。结果还应进行数字签名，例如使用XML数字签名[W3C.REC-xmldsig-core-20020212]。然而，请注意，简单的起源断言可能无法向终端系统提供足够的有用信息，因为它无法很好地知道特定签名者被授权代表特定的签名者
geographic area. It might be necessary that certain well-known Certificate Authorities (CAs) vet sources of mapping information and provide special certificates for that purpose. In many cases, a seeker will have to trust its local resolver to vet information for trustworthiness; in turn, the resolver may rely on trusted forest guides to steer it to the correct information.
地理区域。某些著名的证书颁发机构（CA）可能需要审查地图信息的来源，并为此目的提供特殊证书。在许多情况下，搜索者必须信任其本地解析器来检查信息的可信度；反过来，冲突解决程序可能依赖受信任的林指南将其引导到正确的信息。
coverage region corruption: To avoid the possibility of a third party or an untrustworthy member of a server population claiming a coverage region that it is not authorized for, any node introducing a new service boundary MUST sign the object by protecting the data with an XML digital signature [W3C.REC-xmldsig-core-20020212]. A recipient MUST verify, through a local policy mechanism, that the signing entity is indeed authorized to speak for that region. Determining who can speak for a particular region is inherently difficult unless there is a small set of authorizing entities that participants in the mapping architecture can trust. Receiving systems should be particularly suspicious if an existing coverage region is replaced with a new one with a new mapping address. In many cases, trust will be mediated: a seeker will have a trust relationship with a resolver, and the resolver, in turn, will contact a trusted forest guide.
覆盖区域损坏：为避免第三方或服务器群中不可信成员声称其未获得授权的覆盖区域的可能性，引入新服务边界的任何节点都必须通过使用XML数字签名保护数据对对象进行签名[W3C.REC-xmldsig-core-20020212]。接收人必须通过本地策略机制验证签名实体确实有权代表该地区发言。确定谁可以代表某个特定区域发言本身就很困难，除非映射体系结构中的参与者可以信任一小部分授权实体。如果将现有覆盖区域替换为具有新映射地址的新覆盖区域，则接收系统应特别可疑。在许多情况下，信任将被调解：寻求者将与冲突解决程序建立信任关系，而冲突解决程序反过来将联系受信任的林向导。
Additional threats that need to be addressed by operational measures include denial-of-service attacks [PHONE-BCP].
需要通过操作措施解决的其他威胁包括拒绝服务攻击[PHONE-BCP]。
Jari Arkko, Richard Barnes, Cullen Jennings, Jong Yul Kim, Otmar Lendl, Matt Lepinski, Chris Newman, Andrew Newton, Jon Peterson, Schida Schubert, Murugaraj Shanmugam, Richard Stastny, Hannes Tschofenig, and Karl Heinz Wolf provided helpful comments.
贾里·阿尔科、理查德·巴恩斯、卡伦·詹宁斯、金钟郁、奥特马尔·伦德尔、马特·莱宾斯基、克里斯·纽曼、安德鲁·牛顿、乔恩·彼得森、希达·舒伯特、穆鲁格拉吉·尚穆加姆、理查德·斯塔斯尼、汉内斯·茨霍芬尼和卡尔·海因茨·沃尔夫提供了有益的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.
[RFC5031]Schulzrinne，H.，“应急和其他知名服务的统一资源名称（URN）”，RFC 5031，2008年1月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[RFC5222]Hardie，T.，Newton，A.，Schulzrinne，H.，和H.Tschofenig，“丢失：位置到服务转换协议”，RFC 5222，2008年8月。
[RFC5223] 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.
[RFC5223]Schulzrinne，H.，Polk，J.，和H.Tschofenig，“使用动态主机配置协议（DHCP）发现位置到服务转换（丢失）服务器”，RFC 52232008年8月。
[CONFIG-FRAME] Channabasappa, S., "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, February 2008.
[CONFIG-FRAME]Channabasappa，S.，“会话启动协议用户代理配置文件交付框架”，正在进行的工作，2008年2月。
[ECRIT-FRAME] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling using Internet Multimedia", Work in Progress, March 2009.
[ECRIT-FRAME]Rosen，B.，Schulzrinne，H.，Polk，J.，和A.Newton，“使用互联网多媒体进行紧急呼叫的框架”，正在进行的工作，2009年3月。
[LOST-SYNC] Schulzrinne, H. and H. Tschofenig, "Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements", Work in Progress, March 2009.
[LOST-SYNC]Schulzrinne，H.和H.Tschofenig，“同步位置到服务转换（LOST）基于协议的服务边界和映射元素”，正在进行的工作，2009年3月。
[PHONE-BCP] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, March 2009.
[PHONE-BCP]Rosen，B.和J.Polk，“支持紧急呼叫的通信服务当前最佳实践”，正在进行的工作，2009年3月。
[RFC3528] Zhao, W., Schulzrinne, H., and E. Guttman, "Mesh-enhanced Service Location Protocol (mSLP)", RFC 3528, April 2003.
[RFC3528]Zhao，W.，Schulzrinne，H.，和E.Guttman，“网状增强服务定位协议（mSLP）”，RFC 35282003年4月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012]Schulzrinne，H.和R.Marshall，“利用互联网技术解决紧急情况的要求”，RFC 5012，2008年1月。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069]Taylor，T.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[W3C.REC-xmldsig-core-20020212] Solo, D., Eastlake, D., and J. Reagle, "XML-Signature Syntax and Processing", World Wide Web Consortium FirstEdition REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[W3C.REC-xmldsig-core-20020212]Solo，D.，Eastlake，D.，和J.Reagle，“XML签名语法和处理”，万维网联盟第一版REC-xmldsig-core-20020212，2002年2月<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
Author's Address
作者地址
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