Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 6739 Columbia University
Category: Experimental H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
October 2012
Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 6739 Columbia University
Category: Experimental H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
October 2012
Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol
基于位置到服务转换（LoST）协议同步服务边界和<mapping>元素
Abstract
摘要
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services.
位置到服务转换（LoST）协议是一种基于XML的协议，用于将服务标识符和大地测量或城市位置信息映射到服务URI和服务边界。特别是，它可用于确定紧急服务的位置适当的公共安全应答点（PSAP）。
The <mapping> element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service.
LoST protocol specification中的<mapping>元素封装了有关服务边界的信息，并限定了一个区域，在该区域内，所有位置都映射到给定服务的同一服务统一资源标识符（URI）或URI集。
This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping> elements between two entities. Exchanging cached <mapping> elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping> element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol.
本文档定义了一个XML协议，用于在两个节点之间交换这些映射。此机制设计用于在两个实体之间交换权威的<mapping>元素。交换缓存的<mapping>元素（即非权威元素）是可能的，但不是预想的。即使从丢失的规范中重用了<mapping>元素格式，本文档中的机制也可以在不使用丢失的协议的情况下使用。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6739.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6739.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. A Motivating Example . . . . . . . . . . . . . . . . . . . . . 4
4. Querying for Mappings with a
<getMappingsRequest>/<getMappingsResponse> Exchange . . . . . 9
4.1. Behavior of the LoST Sync Destination . . . . . . . . . . 9
4.2. Behavior of the LoST Sync Source . . . . . . . . . . . . . 10
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Pushing Mappings via <pushMappings> and
<pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 12
5.1. Behavior of the LoST Sync Source . . . . . . . . . . . . . 12
5.2. Behavior of the LoST Sync Destination . . . . . . . . . . 13
5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Operational Considerations . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. Media Type Registration . . . . . . . . . . . . . . . . . 21
10.2. LoST Sync RELAX NG Schema Registration . . . . . . . . . . 22
10.3. LoST Synchronization Namespace Registration . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. A Motivating Example . . . . . . . . . . . . . . . . . . . . . 4
4. Querying for Mappings with a
<getMappingsRequest>/<getMappingsResponse> Exchange . . . . . 9
4.1. Behavior of the LoST Sync Destination . . . . . . . . . . 9
4.2. Behavior of the LoST Sync Source . . . . . . . . . . . . . 10
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Pushing Mappings via <pushMappings> and
<pushMappingsResponse> . . . . . . . . . . . . . . . . . . . . 12
5.1. Behavior of the LoST Sync Source . . . . . . . . . . . . . 12
5.2. Behavior of the LoST Sync Destination . . . . . . . . . . 13
5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Operational Considerations . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10.1. Media Type Registration . . . . . . . . . . . . . . . . . 21
10.2. LoST Sync RELAX NG Schema Registration . . . . . . . . . . 22
10.3. LoST Synchronization Namespace Registration . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 24
Since the early days of emergency services, there has been a desire to route emergency calls to Public Safety Answering Points (PSAPs) that are nearest to the location of the emergency caller. For this purpose each PSAP discloses one or more service boundaries so that this information can be used to select the appropriate PSAP and to route the call to it. RFC 5222 [RFC5222] defines this data structure in the following way:
从紧急服务的早期开始，人们就希望将紧急呼叫转接到离紧急呼叫者最近的公共安全应答点（PSAP）。为此，每个PSAP公开了一个或多个服务边界，以便该信息可用于选择适当的PSAP并将呼叫路由到它。RFC 5222[RFC5222]以以下方式定义此数据结构：
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集。服务边界可以由几个不连续的几何形状组成。
RFC 5222 [RFC5222] also specifies the data structure itself as the <mapping> element.
RFC 5222[RFC5222]还将数据结构本身指定为<mapping>元素。
This document reuses this existing data structure and defines an XML-based protocol to exchange authoritative service boundaries between two entities, namely, the LoST Sync source and the LoST Sync destination. This protocol can be used whether or not the LoST protocol is used for querying for service boundary information.
本文档重用了现有的数据结构，并定义了一个基于XML的协议，以在两个实体（即丢失同步源和丢失同步目标）之间交换权威服务边界。无论丢失的协议是否用于查询服务边界信息，都可以使用该协议。
The rest of the document is structured as follows. Section 3 starts with an example usage of the LoST protocol. In Sections 4, 5, 6, and 7, we describe the protocol semantics, transport considerations, and the schema. Finally, we conclude with operational, security, and IANA considerations in Sections 8, 9, and 10.
文档的其余部分的结构如下所示。第3节从丢失协议的示例用法开始。在第4、5、6和7节中，我们描述了协议语义、传输注意事项和模式。最后，我们在第8、9和10节中总结了操作、安全和IANA方面的考虑。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document reuses terminology introduced by the mapping architecture document [RFC5582], such as 'coverage region', 'forest guide', 'mapping', and 'authoritative mapping server'. This document also uses the term 'ESRP', defined in [RFC5012].
本文档重用了映射体系结构文档[RFC5582]引入的术语，如“覆盖区域”、“林指南”、“映射”和“权威映射服务器”。本文件还使用了[RFC5012]中定义的术语“ESRP”。
Throughout this document, we use the terms 'LoST Sync source' and 'LoST Sync destination' to denote the protocol endpoints of the exchange. The protocol is referred to as 'LoST Sync' within the text.
在本文档中，我们使用术语“丢失同步源”和“丢失同步目标”来表示exchange的协议端点。该协议在文本中称为“失去同步”。
The LoST Sync mechanism can, for example, be used in the LoST architecture, as specified in [RFC5582]. There, LoST servers cooperate to provide an ubiquitous, globally scalable, and resilient mapping service. In the LoST mapping architecture, LoST servers can peer, i.e., have an ongoing data exchange relationship. Peering relationships are set up manually, based on local policies. A LoST server may peer with any number of other LoST servers. Forest guides peer with other forest guides; authoritative mapping servers peer with forest guides and other authoritative servers, either in the same cluster or above or below them in the tree. Authoritative mapping servers push coverage regions "up" the tree, i.e., from child nodes to parent nodes. The child informs the parent of the geospatial or civic region that it covers for a specific service.
例如，如[RFC5582]所述，丢失同步机制可用于丢失体系结构。在那里，丢失的服务器相互协作，提供无处不在、全球可扩展且具有弹性的映射服务。在丢失的映射体系结构中，丢失的服务器可以对等，即具有持续的数据交换关系。对等关系是基于本地策略手动设置的。丢失的服务器可以与任何数量的其他丢失的服务器进行对等。森林向导与其他森林向导同行；权威映射服务器与林指南和其他权威服务器对等，可以在同一集群中，也可以在树的上面或下面。权威映射服务器将覆盖区域推到树的“上”，即从子节点推到父节点。子项通知地理空间或城市区域的父项，该子项覆盖特定服务。
Consider a hypothetical deployment of LoST in two countries, for example, Austria and Finland. Austria, in our example, runs three authoritative mapping servers labeled as 'East', 'West', and 'Vienna', where the former two cover the entire country except for Vienna, which is covered by a separate LoST server. There may be other caching LoST servers run by ISPs, universities, and Voice Service Providers (VSPs), but they are not relevant for this illustration. Finland, on the other hand, decided to only deploy a single LoST server that also acts as a forest guide. For this simplistic illustration, we assume that only one service is available, namely 'urn:service:sos' since otherwise the number of stored mappings would have to be multiplied by the number of used services.
假设一个假设的部署在两个国家，例如奥地利和芬兰。在我们的例子中，奥地利运行着三个权威的地图服务器，分别标记为“东”、“西”和“维也纳”，其中前两个服务器覆盖除维也纳以外的整个国家，维也纳由一个单独的丢失服务器覆盖。可能还有其他由ISP、大学和语音服务提供商（VSP）运行的缓存丢失服务器，但它们与本示例无关。另一方面，芬兰决定只部署一台丢失的服务器，该服务器也可作为森林指南。对于这个简单的说明，我们假设只有一个服务可用，即“urn:service:sos”，因为否则存储映射的数量必须乘以已使用服务的数量。
Figure 1 shows the example deployment.
图1显示了示例部署。
+---LoST-Sync-->\\ //<--LoST-Sync----+
| ----- |
| |
\/ \/
----- -----
// \\ // \\
/ \ / \
| Forest | | Forest |
| Guide | | Guide |
| Austria | | Finland
\ / \ /
+--------->\\ //<--------+ \\ //
| ----- | -----
| /\ | |
LoST | LoST //------\\
Sync LoST Sync |Co-Located|
| Sync | | LoST |
\/ | \/ | Server |
//----\\ \/ //----\\ \\------//
| LoST | //----\\ | LoST |
| Server | | LoST | | Server |
| 'East' | | Server | |'Vienna'|
\\----// | 'West' | \\----//
\\----//
+---LoST-Sync-->\\ //<--LoST-Sync----+
| ----- |
| |
\/ \/
----- -----
// \\ // \\
/ \ / \
| Forest | | Forest |
| Guide | | Guide |
| Austria | | Finland
\ / \ /
+--------->\\ //<--------+ \\ //
| ----- | -----
| /\ | |
LoST | LoST //------\\
Sync LoST Sync |Co-Located|
| Sync | | LoST |
\/ | \/ | Server |
//----\\ \/ //----\\ \\------//
| LoST | //----\\ | LoST |
| Server | | LoST | | Server |
| 'East' | | Server | |'Vienna'|
\\----// | 'West' | \\----//
\\----//
Figure 1: LoST Deployment Example
图1：丢失的部署示例
The nodes are configured as follows:
节点配置如下：
Forest Guide Austria: This forest guide contains mappings for the three authoritative mapping servers (East, West, and Vienna) describing the area for which they are responsible. Note that each mapping contains a service URN, and these mappings point to LoST servers rather than to PSAPs or Emergency Services Routing Proxies (ESRPs).
奥地利森林指南：本森林指南包含三个权威映射服务器（东部、西部和维也纳）的映射，描述了它们负责的区域。请注意，每个映射都包含一个服务URN，这些映射指向丢失的服务器，而不是PSAP或紧急服务路由代理（ESRP）。
LoST Server 'East': This LoST server contains all the mappings to PSAPs covering the eastern part of the country.
丢失的服务器“East”：此丢失的服务器包含覆盖该国东部的所有PSAP映射。
Additionally, the LoST server aggregates all the information it has and provides an abstracted view towards the forest guide indicating that it is responsible for a certain area (for a given service and for a given location profile). For our example, the structure of a mapping is shown below:
此外，丢失的服务器聚合了它拥有的所有信息，并提供了一个指向林指南的抽象视图，表明它负责某个区域（对于给定的服务和给定的位置配置文件）。对于我们的示例，映射的结构如下所示：
<mapping
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
expires="2009-01-01T01:44:33Z"
lastUpdated="2009-12-01T01:00:00Z"
source="east-austria.lost-example.com"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
<displayName xml:lang="en">LoST Server 'East'</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos> ... </gml:pos>
..... list of coordinates for
boundary of LoST server 'East'
<gml:pos> ... </gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri/>
</mapping>
<mapping
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml"
expires="2009-01-01T01:44:33Z"
lastUpdated="2009-12-01T01:00:00Z"
source="east-austria.lost-example.com"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109">
<displayName xml:lang="en">LoST Server 'East'</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos> ... </gml:pos>
..... list of coordinates for
boundary of LoST server 'East'
<gml:pos> ... </gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri/>
</mapping>
Figure 2: Forest Guide Austria Mapping XML Snippet
图2:ForestGuide奥地利映射XML片段
Note that the XML code snippet in Figure 2 serves illustrative purposes only and does not validate. As can be seen in this example, the <uri> element is absent, and the 'source' attribute identifies the LoST server, namely "east-austria.lost-example.com".
请注意，图2中的XML代码片段仅用于说明目的，不进行验证。如本例所示，<uri>元素不存在，“source”属性标识丢失的服务器，即“east austria.LoST example.com”。
The mapping shown above is what is the LoST server "east-austria.lost-example.com" provides to the Austrian forest guide.
上面显示的映射是“east austria.LoST example.com”向《奥地利森林指南》提供的丢失服务器。
LoST Server 'West': This LoST server contains all the mappings to PSAPs covering the western half of the country.
丢失的服务器“West”：此丢失的服务器包含覆盖该国西部的所有PSAP映射。
LoST Server 'Vienna': This LoST server contains all the mappings to PSAPs for the city of Vienna.
丢失的服务器“Vienna”：此丢失的服务器包含维也纳市PSAP的所有映射。
Forest Guide Finland: In our example, we assume that Finland deploys a single ESRP for the entire country as their IP-based emergency services solution. There is only a single LoST server, and it is co-located with the forest guide, as shown in Figure 1. The mapping data this forest guide (FG) then distributes via LoST Sync is shown in Figure 3.
芬兰森林指南：在我们的示例中，我们假设芬兰为整个国家部署了一个ESRP作为其基于IP的应急服务解决方案。只有一个丢失的服务器，它与林指南位于同一位置，如图1所示。该林指南（FG）随后通过丢失同步分发的映射数据如图3所示。
<mapping xmlns="urn:ietf:params:xml:ns:lost1"
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="finland.lost-example.com"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">Finland ESRP</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>FI</country>
</civicAddress>
</serviceBoundary>
<uri/>
</mapping>
<mapping xmlns="urn:ietf:params:xml:ns:lost1"
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="finland.lost-example.com"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">Finland ESRP</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>FI</country>
</civicAddress>
</serviceBoundary>
<uri/>
</mapping>
Figure 3: Forest Guide Finland Mapping XML Snippet
图3:ForestGuide芬兰映射XML片段
An example mapping stored at the co-located LoST server is shown in Figure 4.
图4显示了存储在同一位置的丢失服务器上的映射示例。
<mapping xmlns="urn:ietf:params:xml:ns:lost1"
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="finland.lost-example.com"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">Finland ESRP</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>FI</country>
</civicAddress>
</serviceBoundary>
<uri>sip:esrp@finland-example.com</uri>
<uri>xmpp:esrp@finland-example.com</uri>
<serviceNumber>112</serviceNumber>
</mapping>
<mapping xmlns="urn:ietf:params:xml:ns:lost1"
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="finland.lost-example.com"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">Finland ESRP</displayName>
<service>urn:service:sos</service>
<serviceBoundary profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>FI</country>
</civicAddress>
</serviceBoundary>
<uri>sip:esrp@finland-example.com</uri>
<uri>xmpp:esrp@finland-example.com</uri>
<serviceNumber>112</serviceNumber>
</mapping>
Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping XML Snippet
图4:Forest Guide Finland/Co-Located LoST Server映射XML片段
The LoST Sync mechanism described in this document can be run between the two forest guides. That way, the three mappings stored in the FG Austria are sent to the FG Finland, and a single mapping in the FG Finland is sent to the FG Austria. Additionally, the three Austrian LoST servers could utilize LoST Sync to inform the Austrian FG about their boundaries. These three authoritative mapping servers in
本文档中描述的丢失同步机制可以在两个林指南之间运行。这样，存储在FG Austria中的三个映射将发送到FG Finland，而FG Finland中的一个映射将发送到FG Austria。此外，三台奥地利丢失服务器可以利用丢失同步向奥地利FG通报其边界。中的这三个权威映射服务器
Austria would be responsible for maintaining their own mapping information. Since the amount of data being exchanged is small and the expected rate of change is low, the nodes are configured to always exchange all their mapping information whenever a change happens.
奥地利将负责维护自己的地图信息。由于交换的数据量很小，且预期的更改率很低，因此节点被配置为在发生更改时始终交换其所有映射信息。
This document defines two types of exchanges, which are best described by the exchange between two nodes as shown in Figures 5 and 6. The protocol exchange always runs between a LoST Sync source and a LoST Sync destination. Node A in the examples of Figures 5 and 6 has mappings that Node B is going to retrieve. Node A acts as the source for the data and Node B is the destination.
本文档定义了两种类型的交换，最好通过图5和图6所示的两个节点之间的交换来描述。协议交换始终在丢失同步源和丢失同步目标之间运行。图5和图6示例中的节点A具有节点B将要检索的映射。节点A作为数据源，节点B作为目的地。
The <getMappingsRequest> request allows a LoST Sync source to request mappings from a LoST Sync destination.
<getMappingsRequest>请求允许丢失同步源从丢失同步目标请求映射。
+---------+ +---------+
| Node B | | Node A |
| acting | | acting |
| as | | as |
| LoST | | LoST |
| Sync | | Sync |
| Dest. | | Source |
+---------+ +---------+
| |
| |
| |
| <getMappingsRequest> |
|----------------------------->|
| |
| <getMappingsResponse> |
|<-----------------------------|
| |
| |
| |
+---------+ +---------+
| Node B | | Node A |
| acting | | acting |
| as | | as |
| LoST | | LoST |
| Sync | | Sync |
| Dest. | | Source |
+---------+ +---------+
| |
| |
| |
| <getMappingsRequest> |
|----------------------------->|
| |
| <getMappingsResponse> |
|<-----------------------------|
| |
| |
| |
Figure 5: Querying for Mappings with a <getMappingsRequest> Message
Figure 5: Querying for Mappings with a <getMappingsRequest> Message
Note that in the exchange illustrated in Figure 5, Node B is issuing the first request and plays the role of the HTTPS client, and Node A plays the role of the HTTPS server.
注意，在图5所示的交换中，节点B发出第一个请求并扮演HTTPS客户端的角色，节点A扮演HTTPS服务器的角色。
In Figure 6, the <pushMappingsRequest> exchange allows a LoST Sync source to push mappings to a LoST Sync destination. In this example, we assume that Node A has been configured maintain state about the mappings it had pushed to Node B.
在图6中，<pushMappingsRequest>exchange允许丢失的同步源将映射推送到丢失的同步目标。在本例中，我们假设节点A已配置为维护其推送到节点B的映射的状态。
This document does not define a publish/subscribe mechanism. Such a mechanism would allow Node B to tell Node A what mappings it is interested in. This document also does not define a mechanism for nodes to find out to which other entities mappings have to be pushed.
本文档未定义发布/订阅机制。这种机制将允许节点B告诉节点a它感兴趣的映射。本文档也没有为节点定义一种机制，以确定必须将其他实体映射推送到哪些实体。
+---------+ +---------+
| Node A | | Node B |
| acting | | acting |
| as | | as |
| LoST | | LoST |
| Sync | | Sync |
| Source | | Dest. |
+---------+ +---------+
| |
| |
| |
| <pushMappingsRequest> |
|----------------------------->|
| |
| <pushMappingsResponse> |
|<-----------------------------|
| |
| |
| |
+---------+ +---------+
| Node A | | Node B |
| acting | | acting |
| as | | as |
| LoST | | LoST |
| Sync | | Sync |
| Source | | Dest. |
+---------+ +---------+
| |
| |
| |
| <pushMappingsRequest> |
|----------------------------->|
| |
| <pushMappingsResponse> |
|<-----------------------------|
| |
| |
| |
Figure 6: Pushing Mappings with a <pushMappingsRequest> Message
Figure 6: Pushing Mappings with a <pushMappingsRequest> Message
Node A issuing the first request in Figure 6 plays the role of the HTTPS client, and Node B plays the role of the HTTPS server.
图6中发出第一个请求的节点A扮演HTTPS客户端的角色，节点B扮演HTTPS服务器的角色。
4. Querying for Mappings with a <getMappingsRequest>/ <getMappingsResponse> Exchange
4. 使用<getMappingsRequest>/<getMappingsResponse>交换查询映射
A LoST Sync destination has two ways to retrieve <mapping> elements from a LoST Sync source.
丢失同步目标有两种方法从丢失同步源检索<mapping>元素。
1. When the Lost Sync destination does not have any mappings, it submits an empty <getMappingsRequest> message, as shown in Figure 7. This indicates that it wishes to retrieve all mappings from the LoST Sync source. Note that the request does not propagate further to other nodes.
1. 当丢失的同步目标没有任何映射时，它会提交一条空的<getMappingsRequest>消息，如图7所示。这表示它希望从丢失的同步源检索所有映射。请注意，请求不会进一步传播到其他节点。
2. In case a LoST Sync destination node has already obtained mappings in previous exchanges, then it may want to check whether these mappings have been updated in the meanwhile. The policy regarding when to poll for updated mapping information is outside the scope of this document. The <getMappingsRequest> message with one or more <exists> child element(s) allows the source to only return mappings that are missing at the destination or have been updated.
2. 如果丢失同步的目标节点已经在以前的交换中获得了映射，那么它可能需要检查这些映射是否同时被更新。关于何时轮询更新的映射信息的策略超出了本文档的范围。带有一个或多个<exists>子元素的<getMappingsRequest>消息只允许源返回在目标位置丢失或已更新的映射。
After issuing the <getMappingsRequest> message, the LoST Sync destination waits for the <getMappingsResponse> message. In case of a successful response, the LoST Sync destination stores the received mappings and determines which mappings to update.
发出<getMappingsRequest>消息后，丢失的同步目标将等待<getMappingsResponse>消息。如果响应成功，丢失的同步目标将存储收到的映射并确定要更新的映射。
When a LoST Sync source receives an empty <getMappingsRequest> message, then all locally available mappings MUST be returned.
当丢失的同步源收到空的<getMappingsRequest>消息时，必须返回所有本地可用的映射。
When a LoST Sync source receives a <getMappingsRequest> message with one or more <exists> child element(s), then it MUST consult with the local mapping database to determine whether any of the mappings of the client is stale and whether there are mappings locally that the client does not yet have. The former can be determined by finding mappings corresponding to the 'source' and 'sourceID' attributes where a mapping with a more recent 'lastUpdated' date exists.
当丢失的同步源收到带有一个或多个<exists>子元素的<getMappingsRequest>消息时，它必须咨询本地映射数据库，以确定客户端的任何映射是否过时，以及是否存在客户端尚未在本地拥有的映射。前者可以通过查找与“source”和“sourceID”属性相对应的映射来确定，其中存在具有较新“lastUpdated”日期的映射。
Processing a <getMappingsRequest> message MAY lead to a successful response in the form of a <getMappingsResponse> or an <errors> message. Only the <badRequest>, <forbidden>, <internalError>, and <serverTimeout> errors, defined in [RFC5222], are used by this specification. Neither the <redirect> nor the <warnings> messages are reused by this message.
处理<getMappingsRequest>消息可能导致以<getMappingsResponse>或<errors>消息形式的成功响应。本规范仅使用[RFC5222]中定义的<badRequest>、<forbidden>、<internalError>和<serverTimeout>错误。此消息不会重用<redirect>或<warnings>消息。
The first example shows an empty <getMappingsRequest> message that would retrieve all locally stored mappings at the LoST Sync source.
第一个示例显示一条空的<getMappingsRequest>消息，该消息将在丢失的同步源中检索所有本地存储的映射。
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1"/>
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1"/>
Figure 7: Example of Empty <getMappingsRequest> Message
Figure 7: Example of Empty <getMappingsRequest> Message
A further example request is shown in Figure 8, and the corresponding response is depicted in Figure 9. In this example, the <getMappingsRequest> element contains information about the mapping that is locally available to the client inside the
另一个请求示例如图8所示，相应的响应如图9所示。在本例中，<getMappingsRequest>元素包含有关映射的信息，该映射在
<mapping-fingerprint> element (with source="authoritative.bar.example", sourceId="7e3f40b098c711dbb6060800200c9a66", and lastUpdated="2006- 11-01T01:00:00Z"). The query asks for mappings that are more recent than the available one as well as any missing mapping.
<mapping fingerprint>元素（带有source=“authoritional.bar.example”、sourceId=“7e3f40b098c711db6060800200c9a66”和lastUpdated=“2006-11-01T01:00:00Z”）。该查询要求使用比可用映射更新的映射以及任何缺少的映射。
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1">
<exists>
<mapping-fingerprint source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2006-11-01T01:00:00Z">
</mapping-fingerprint>
</exists>
</getMappingsRequest>
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1">
<exists>
<mapping-fingerprint source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2006-11-01T01:00:00Z">
</mapping-fingerprint>
</exists>
</getMappingsRequest>
Figure 8: Example <getMappingsRequest> Message
Figure 8: Example <getMappingsRequest> Message
The response to the above request is shown in Figure 9. A more recent mapping was available with the identification of source="authoritative.bar.example" and sourceId="7e3f40b098c711dbb6060800200c9a66". Only one missing mapping, with source "authoritative.foo.example", was found and returned.
对上述请求的响应如图9所示。可通过标识source=“authoritional.bar.example”和sourceId=“7e3f40b098c711db6060800200c9a66”获得更新的映射。只找到并返回了一个缺少的映射，源代码为“authoritive.foo.example”。
<?xml version="1.0" encoding="UTF-8"?>
<sync:getMappingsResponse
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml">
<?xml version="1.0" encoding="UTF-8"?>
<sync:getMappingsResponse
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml">
<mapping source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en">Leonia Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>NJ</A1>
<A3>Leonia</A3>
<PC>07605</PC>
</civicAddress>
</serviceBoundary>
<mapping source="authoritative.bar.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en">Leonia Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>NJ</A1>
<A3>Leonia</A3>
<PC>07605</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:police@leonianj2.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<uri>sip:police@leonianj2.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.foo.example"
sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en">New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>37.775 -122.4194</gml:pos>
<gml:pos>37.555 -122.4194</gml:pos>
<gml:pos>37.555 -122.4264</gml:pos>
<gml:pos>37.775 -122.4264</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.foo.example"
sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en">New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>37.775 -122.4194</gml:pos>
<gml:pos>37.555 -122.4194</gml:pos>
<gml:pos>37.555 -122.4264</gml:pos>
<gml:pos>37.775 -122.4264</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
</sync:getMappingsResponse>
</sync:getMappingsResponse>
Figure 9: Example <getMappingsResponse> Message
Figure 9: Example <getMappingsResponse> Message
When a LoST Sync source obtains new information that is of interest to its peers, it may push the new mappings to its peers. Configuration settings at both peers decide whether this functionality is used and what mappings are pushed to which other peers. New mappings may arrive through various means, such as a manual addition to the local mapping database, or through the interaction with other entities. Deleting mappings may also trigger a protocol interaction.
当丢失的同步源获得其对等方感兴趣的新信息时，它可能会将新映射推送到其对等方。两个对等点的配置设置决定是否使用此功能以及将哪些映射推送到其他对等点。新映射可以通过各种方式到达，例如手动添加到本地映射数据库，或者通过与其他实体的交互。删除映射也可能触发协议交互。
The LoST Sync source SHOULD keep track of which LoST Sync destination it has pushed <mapping> elements to. If it does not keep state information, then it always has to push the complete data set. As discussed in Section 5.1 of [RFC5222], <mapping> elements are identified by the 'source', 'sourceID', and 'lastUpdated' attributes. A mapping is considered the same if these three attributes match.
丢失的同步源应跟踪它已将<mapping>元素推送到哪个丢失的同步目标。如果它不保留状态信息，那么它总是必须推送完整的数据集。如[RFC5222]第5.1节所述，<mapping>元素由“source”、“sourceID”和“lastUpdated”属性标识。如果这三个属性匹配，则认为映射是相同的。
A <pushMappings> request sent by a LoST Sync source MUST contain one or more <mapping> elements.
丢失同步源发送的<pushMappings>请求必须包含一个或多个<mapping>元素。
To delete a mapping, the content of the mapping is left empty, i.e., the <mapping> element only contains the 'source', 'sourceID', 'lastUpdated', and 'expires' attributes. Figure 10 shows an example request where the mapping with the source="nj.us.example", sourceId="123", lastUpdated="2008-11-01T01:00:00Z", and expires="2008-11-01T01:00:00Z" is requested to be deleted. Note that the 'expires' attribute is required per the schema definition but will be ignored in processing the request on the receiving side. A sync source may want to delete the mapping from its internal mapping database but has to remember the peers to which it has distributed this update unless it has other ways to ensure that databases do not get out of sync.
要删除映射，映射的内容将保留为空，即<mapping>元素仅包含“source”、“sourceID”、“lastUpdated”和“expires”属性。图10显示了一个请求示例，其中请求删除与source=“nj.us.example”、sourceId=“123”、lastUpdated=“2008-11-01T01:00:00Z”和expires=“2008-11-01T01:00:00Z”的映射。请注意，“expires”属性是架构定义所必需的，但在接收端处理请求时将被忽略。同步源可能希望从其内部映射数据库中删除映射，但必须记住已向其分发此更新的对等方，除非有其他方法确保数据库不会失去同步。
When a LoST Sync destination receives a <pushMappingsRequest> message, then the cache with the existing mappings is inspected to determine whether the received mapping should lead to an update of an already existing mapping, should create a new mapping in the cache, or should be discarded.
当丢失的同步目标接收到<pushMappingsRequest>消息时，将检查具有现有映射的缓存，以确定接收到的映射是否应导致对现有映射的更新，是否应在缓存中创建新映射，或者是否应丢弃。
If a newly received mapping has a more recent time in its 'lastUpdated' attribute, it MUST update an existing mapping that has matching 'source' and 'sourceID' attributes.
如果新收到的映射在其“lastUpdated”属性中具有较新的时间，则它必须更新具有匹配的“source”和“sourceID”属性的现有映射。
If the received mapping does not match with any existing mapping based on the 'source' and 'sourceId', then it MUST be added to the local cache as an independent mapping.
如果收到的映射与任何基于“源”和“源ID”的现有映射不匹配，则必须将其作为独立映射添加到本地缓存中。
If a <pushMappingsRequest> message with an empty <mapping> element is received, then a corresponding mapping has to be determined based on the 'source' and the 'sourceID'.
如果收到带有空<mapping>元素的<pushMappingsRequest>消息，则必须根据“源”和“源ID”确定相应的映射。
If no mapping can be identified, then an <errors> response MUST be returned that contains the <notDeleted> child element. The <notDeleted> element MAY contain a 'message' attribute with an error description used for debugging purposes. The <notDeleted> element MUST contain the <mapping> element(s) that caused the error.
如果无法识别映射，则必须返回包含<notDeleted>子元素的<errors>响应。<notDeleted>元素可能包含一个带有错误描述的“message”属性，用于调试目的。<notDeleted>元素必须包含导致错误的<mapping>元素。
The response to a <pushMappingsRequest> request is a <pushMappingsResponse> message. With this specification, a successful response message returns no additional elements, whereas an <errors> response is returned in the response message if the request failed. Only the <badRequest>, <forbidden>, <internalError>, or <serverTimeout> errors defined in Section 13.1 of [RFC5222] are used. The <redirect> and <warnings> messages are not used for this query/response.
对<pushMappingsRequest>请求的响应是<pushMappingsResponse>消息。使用此规范，成功的响应消息不返回其他元素，而如果请求失败，则在响应消息中返回<errors>响应。仅使用[RFC5222]第13.1节中定义的<badRequest>、<forbidden>、<internalError>或<serverTimeout>错误。<redirect>和<warnings>消息不用于此查询/响应。
If the set of nodes that are synchronizing their data does not form a tree, it is possible that the same information arrives through several other nodes. This is unavoidable but generally only imposes a modest overhead. (It would be possible to create a spanning tree in the same fashion as IP multicast, but the complexity does not seem warranted, given the relatively low volume of data.)
如果正在同步其数据的节点集未形成树，则相同的信息可能通过其他几个节点到达。这是不可避免的，但通常只会带来适度的开销。（以与IP多播相同的方式创建生成树是可能的，但考虑到相对较低的数据量，其复杂性似乎没有必要。）
An example is shown in Figure 10. Imagine a LoST node that obtained two new mappings identified as follows:
图10显示了一个示例。设想一个丢失的节点获得了两个新映射，如下所示：
o source="authoritative.example" sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11-26T01:00:00Z"
o source=“authoritional.example”sourceId=“7E3F40B098C711DB6060800200C9A66”lastUpdated=“2008-11-26T01:00:00Z”
o source="authoritative.example" sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11-01T01:00:00Z"
o source=“authoritional.example”sourceId=“7E3F40B098C711DB6060111111111”lastUpdated=“2008-11-01T01:00:00Z”
These two mappings have to be added to the peer's mapping database.
必须将这两个映射添加到对等映射数据库中。
Additionally, the following mapping has to be deleted:
此外，必须删除以下映射：
o source="nj.us.example" sourceId="123" lastUpdated="2008-11-01T01:00:00Z"
o source=“nj.us.example”sourceId=“123”lastUpdated=“2008-11-01T01:00:00Z”
<?xml version="1.0" encoding="UTF-8"?>
<sync:pushMappings
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml">
<?xml version="1.0" encoding="UTF-8"?>
<sync:pushMappings
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml">
<mapping source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en">Leonia Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>NJ</A1>
<A3>Leonia</A3>
<PC>07605</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:police@leonianj.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66"
lastUpdated="2008-11-26T01:00:00Z"
expires="2009-12-26T01:00:00Z">
<displayName xml:lang="en">Leonia Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country>
<A1>NJ</A1>
<A3>Leonia</A3>
<PC>07605</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:police@leonianj.example.org</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en">New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>37.775 -122.4194</gml:pos>
<gml:pos>37.555 -122.4194</gml:pos>
<gml:pos>37.555 -122.4264</gml:pos>
<gml:pos>37.775 -122.4264</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping expires="2009-01-01T01:44:33Z"
lastUpdated="2008-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb606011111111111">
<displayName xml:lang="en">New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<gml:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>37.775 -122.4194</gml:pos>
<gml:pos>37.555 -122.4194</gml:pos>
<gml:pos>37.555 -122.4264</gml:pos>
<gml:pos>37.775 -122.4264</gml:pos>
<gml:pos>37.775 -122.4194</gml:pos>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<mapping source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
<mapping source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</sync:pushMappings>
</sync:pushMappings>
Figure 10: Example <pushMappingsRequest> Message
Figure 10: Example <pushMappingsRequest> Message
In response, the peer performs the necessary operations and updates its mapping database. In particular, it will check whether the other peer is authorized to perform the update and whether the elements and attributes contain values that it understands. In our example, a positive response is returned as shown in Figure 11.
作为响应，对等方执行必要的操作并更新其映射数据库。特别是，它将检查另一个对等方是否有权执行更新，以及元素和属性是否包含它理解的值。在我们的示例中，返回一个肯定响应，如图11所示。
<?xml version="1.0" encoding="UTF-8"?>
<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lostsync1" />
<?xml version="1.0" encoding="UTF-8"?>
<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lostsync1" />
Figure 11: Example <pushMappingsResponse>
Figure 11: Example <pushMappingsResponse>
In case a mapping could not be deleted as requested, the following error response might be returned instead.
如果无法按请求删除映射，则可能会返回以下错误响应。
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
source="nodeA.example.com">
<?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:sync="urn:ietf:params:xml:ns:lostsync1"
source="nodeA.example.com">
<sync:notDeleted
message="Could not delete the indicated mapping."
xml:lang="en">
<sync:notDeleted
message="Could not delete the indicated mapping."
xml:lang="en">
<mapping source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</sync:notDeleted>
</errors>
<mapping source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</sync:notDeleted>
</errors>
Figure 12: Example <errors> Message
Figure 12: Example <errors> Message
LoST Sync needs an underlying protocol transport mechanism to carry requests and responses. This document uses HTTPS as a transport to exchange XML documents. No fallback to HTTP is provided.
丢失同步需要一个底层协议传输机制来承载请求和响应。此文档使用HTTPS作为交换XML文档的传输。没有提供对HTTP的回退。
When using HTTP over Transport Layer Security (TLS) [RFC2818], LoST Sync messages use the POST method. Requests MUST use the Cache-Control response directive "no-cache".
使用HTTP over Transport Layer Security（TLS）[RFC2818]时，丢失的同步消息使用POST方法。请求必须使用缓存控制响应指令“no Cache”。
All LoST Sync responses, including those indicating a LoST warning or error, are carried in 2xx responses, typically 200 (OK). 3xx, 4xx, and 5xx HTTP response codes indicate that the request itself failed or was redirected; these responses do not contain any LoST Sync XML elements.
所有丢失的同步响应，包括指示丢失警告或错误的响应，都以2xx响应形式进行，通常为200（正常）。3xx、4xx和5xx HTTP响应代码表示请求本身失败或被重定向；这些响应不包含任何丢失的同步XML元素。
Note: In order to avoid copying pattern definitions from the LoST Regular Language for XML Next Generation (RELAX NG) schema [RFC5222] to this document, we include it as "lost.rng" (XML syntax) in the RELAX NG schema below.
注意：为了避免将模式定义从LoST Regular Language for XML Next Generation（RELAX NG）模式[RFC5222]复制到本文档中，我们将其作为“LoST.rng”（XML语法）包含在下面的RELAX NG模式中。
<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0" encoding="utf-8"?>
<grammar ns="urn:ietf:params:xml:ns:lostsync1"
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">
<grammar ns="urn:ietf:params:xml:ns:lostsync1"
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">
<include href="lost.rng"/>
<include href="lost.rng"/>
<start combine="choice">
<start combine="choice">
<a:documentation> Location-to-Service Translation (LoST)
Synchronization Protocol</a:documentation>
<a:documentation> Location-to-Service Translation (LoST)
Synchronization Protocol</a:documentation>
<choice>
<ref name="pushMappings"/>
<ref name="pushMappingsResponse"/>
<ref name="getMappingsRequest"/>
<ref name="getMappingsResponse"/>
</choice>
</start>
<choice>
<ref name="pushMappings"/>
<ref name="pushMappingsResponse"/>
<ref name="getMappingsRequest"/>
<ref name="getMappingsResponse"/>
</choice>
</start>
<define name="pushMappings">
<element name="pushMappings">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<define name="pushMappings">
<element name="pushMappings">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<ref name="extensionPoint"/>
</element>
<ref name="extensionPoint"/>
</element>
</define>
</define>
<define name="pushMappingsResponse">
<element name="pushMappingsResponse">
<ref name="extensionPoint"/>
</element>
</define>
<define name="pushMappingsResponse">
<element name="pushMappingsResponse">
<ref name="extensionPoint"/>
</element>
</define>
<define name="getMappingsRequest">
<element name="getMappingsRequest">
<choice>
<ref name="exists"></ref>
<ref name="extensionPoint"/>
</choice>
</element>
</define>
<define name="getMappingsRequest">
<element name="getMappingsRequest">
<choice>
<ref name="exists"></ref>
<ref name="extensionPoint"/>
</choice>
</element>
</define>
<define name="exists">
<element name="exists">
<oneOrMore>
<element name="mapping-fingerprint">
<attribute name="source">
<data type="token"/>
</attribute>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</element>
</define>
<define name="exists">
<element name="exists">
<oneOrMore>
<element name="mapping-fingerprint">
<attribute name="source">
<data type="token"/>
</attribute>
<attribute name="sourceId">
<data type="token"/>
</attribute>
<attribute name="lastUpdated">
<data type="dateTime"/>
</attribute>
<ref name="extensionPoint"/>
</element>
</oneOrMore>
</element>
</define>
<define name="getMappingsResponse">
<element name="getMappingsResponse">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<ref name="extensionPoint"/>
</element>
</define>
<define name="getMappingsResponse">
<element name="getMappingsResponse">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<ref name="extensionPoint"/>
</element>
</define>
<!-- error messages -->
<!-- error messages -->
<define name="notDeleted">
<define name="notDeleted">
<element name="notDeleted">
<ref name="basicException"/>
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
</element>
</define>
</grammar>
<element name="notDeleted">
<ref name="basicException"/>
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
</element>
</define>
</grammar>
It is important to avoid loops when more than two LoST servers use the mechanism described in this document. The example shown in Figure 13 with three LoST servers A, B, and C (each of them acts as a sync source and a sync destination) illustrates the challenge in more detail. A and B synchronize data between each other; the same is true for A and C, and B and C, respectively.
当两台以上丢失的服务器使用本文档中描述的机制时，避免循环非常重要。图13所示的示例中有三个丢失的服务器A、B和C（它们分别充当同步源和同步目标），更详细地说明了这一挑战。A和B彼此之间同步数据；A和C以及B和C分别也是如此。
A -------- B
\ /
\ /
\ /
\ /
C
A -------- B
\ /
\ /
\ /
\ /
C
Figure 13: Synchronization Configuration Example
图13：同步配置示例
Now, imagine that server A adds a new mapping. This mapping is uniquely identified by the combination of "source", "sourceid", and "last updated". Assume that A wants to push this new mapping to B and C. When B obtains this new mapping, it determines that it has to distribute it to its peer C. C also needs to distribute the mapping to its peer B. If the original mapping with the "source", "sourceid", and "last updated" is not modified by either B or C, then these two servers would recognize that they already possess the mapping and can ignore the update.
现在，假设服务器A添加了一个新映射。此映射由“源”、“源ID”和“上次更新”的组合唯一标识。假设A希望将此新映射推送到B和C。当B获得此新映射时，它确定必须将其分发给对等C。C还需要将映射分发给对等B。如果B或C未修改带有“源”、“源ID”和“上次更新”的原始映射，然后，这两个服务器将认识到它们已经拥有映射，并且可以忽略更新。
Implementations MUST NOT modify mappings they receive. An entity acting maliciously would, however, intentionally modify mappings or inject bogus mappings. To avoid the possibility of an untrustworthy member claiming a coverage region for which it is not authorized, authoritative mapping servers MUST sign mappings they distribute using an XML digital signature [W3C.REC-xmldsig-core-20020212]. A recipient MUST verify that the signing entity is indeed authorized to speak for that region. In many cases, this will require an out-of-band agreement to be in place to agree on specific entities to take on this role. Determining who can speak for a particular region is inherently difficult unless there is a small set of authorizing
实现不能修改它们收到的映射。然而，恶意行为的实体会故意修改映射或注入虚假映射。为避免不可信成员声称其未获得授权的覆盖区域的可能性，权威映射服务器必须使用XML数字签名对其分发的映射进行签名[W3C.REC-xmldsig-core-20020212]。接收人必须验证签名实体确实有权代表该地区发言。在许多情况下，这将需要签订带外协议，以商定承担这一角色的具体实体。除非有一小部分授权，否则确定谁能代表某一特定地区发言本身就很困难
entities that participants in the mapping architecture can trust. Receiving systems should be particularly suspicious if an existing coverage region is replaced by a new one that contains a different value in the <uri> element. When mappings are digitally signed, they cannot be modified by intermediate LoST servers.
映射体系结构中的参与者可以信任的实体。如果现有覆盖区域被<uri>元素中包含不同值的新覆盖区域替换，则接收系统应特别可疑。对映射进行数字签名时，中间丢失的服务器无法修改映射。
This document defines a protocol for exchange of authoritative mapping information between two entities. Hence, the protocol operations described in this document require authentication of neighboring nodes.
本文档定义了两个实体之间权威映射信息交换的协议。因此，本文档中描述的协议操作需要对相邻节点进行身份验证。
The LoST Sync client and servers MUST implement TLS and use TLS. Which version(s) ought to be implemented will vary over time and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version but has very limited actual deployment and might not be readily available in implementation tool kits. TLS version 1.0 [RFC2246] is the most widely deployed version and will give the broadest interoperability.
丢失同步客户端和服务器必须实现TLS并使用TLS。应实施的版本将随着时间的推移而变化，并取决于广泛的部署和实施时已知的安全漏洞。在撰写本文时，TLS版本1.2[RFC5246]是最新版本，但实际部署非常有限，可能无法在实现工具包中随时提供。TLS版本1.0[RFC2246]是部署最广泛的版本，将提供最广泛的互操作性。
Mutual authentication between the LoST Sync source and the LoST Sync destination is not necessarily required in all deployments unless an emergency service authority wants to enforce access control prior to the distribution of their <mapping> elements. This may, for example, be the case when certain emergency services networks distribute internal mappings that are not meant for public distribution.
在所有部署中都不一定需要丢失同步源和丢失同步目标之间的相互身份验证，除非紧急服务机构希望在分发其<mapping>元素之前实施访问控制。例如，当某些紧急服务网络分发不用于公共分发的内部映射时，可能会出现这种情况。
An additional threat is caused by compromised or misconfigured LoST servers. A denial of service could be the consequence of an injected mapping. If the mapping data contains a URL that does not exist, then emergency services for the indicated area are not reachable. If all mapping data contains URLs that point to a single PSAP (rather than a large number of PSAPs), then this PSAP is likely to experience overload conditions. If the mapping data contains a URL that points to a server controlled by the adversary itself, then it might impersonate PSAPs.
另一个威胁是由受损或配置错误的丢失服务器造成的。拒绝服务可能是注入映射的结果。如果映射数据包含不存在的URL，则无法访问指定区域的紧急服务。如果所有映射数据都包含指向单个PSAP（而不是大量PSAP）的URL，则此PSAP可能会遇到过载情况。如果映射数据包含指向对手自己控制的服务器的URL，那么它可能会模拟PSAP。
Section 8 discusses this security threat and mandates signed mappings. For unusual changes to the mapping database, approval by a system administrator of the emergency services infrastructure (or a similar expert) may be required before any mappings are installed.
第8节讨论了这种安全威胁，并要求进行签名映射。对于映射数据库的异常更改，在安装任何映射之前，可能需要获得应急服务基础设施系统管理员（或类似专家）的批准。
This specification requests the registration of a new media type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023].
本规范要求根据RFC 4288[RFC4288]的程序和RFC 3023[RFC3023]中的指南注册新媒体类型。
Type name: application
类型名称：应用程序
Subtype name: lostsync+xml
子类型名称：lostsync+xml
Required parameters: none
所需参数：无
Optional parameters: charset
可选参数：字符集
Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023].
与RFC 3023[RFC3023]中指定的application/xml的字符集参数相同。
Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], Section 3.2.
编码注意事项：与[RFC3023]第3.2节中描述的“应用程序/xml”相同。
Security considerations: This content type is designed to carry LoST Synchronization protocol payloads, and the security considerations section of RFC 6739 is applicable. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], Section 10.
安全注意事项：此内容类型旨在承载丢失的同步协议有效载荷，RFC 6739的安全注意事项部分适用。此外，由于该媒体类型使用“+xml”约定，因此它具有与[RFC3023]第10节所述相同的安全注意事项。
Interoperability considerations: None
互操作性注意事项：无
Published specification: RFC 6739
已发布规范：RFC 6739
Applications that use this media type: Emergency and Location-based Systems
使用此媒体类型的应用程序：紧急和基于位置的系统
Additional information:
其他信息：
Magic number(s): None
幻数：无
File extension(s): .lostsyncxml
文件扩展名：.lostsyncxml
Macintosh file type code(s): 'TEXT'
Macintosh文件类型代码：“文本”
Person & email address to contact for further information:
Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Person & email address to contact for further information:
Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Intended usage: LIMITED USE
预期用途：有限用途
Restrictions on usage: None
使用限制：无
Author: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Author: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Change controller:
更改控制器：
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>
The IESG <iesg@ietf.org>
The schema defined in this document has been registered under the XML
schema registry at
http://www.iana.org/assignments/xml-registry/schema.html
The schema defined in this document has been registered under the XML
schema registry at
http://www.iana.org/assignments/xml-registry/schema.html
URI: urn:ietf:params:xml:schema:lostsync1
URI: urn:ietf:params:xml:schema:lostsync1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@gmx.net).
注册人联系人：IETF ECRIT工作组，Hannes Tschofenig（Hannes。Tschofenig@gmx.net).
RELAX NG Schema: The RELAX NG schema that has been registered is contained in Section 7.
RELAXNG模式：已注册的RELAXNG模式包含在第7节中。
The namespace defined in this document has been registered under the
XML namespace registry at
http://www.iana.org/assignments/xml-registry/ns.html
The namespace defined in this document has been registered under the
XML namespace registry at
http://www.iana.org/assignments/xml-registry/ns.html
URI: urn:ietf:params:xml:ns:lostsync1
URI: urn:ietf:params:xml:ns:lostsync1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig (Hannes.Tschofenig@gmx.net).
注册人联系人：IETF ECRIT工作组，Hannes Tschofenig（Hannes。Tschofenig@gmx.net).
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 Synchronization Namespace</title>
</head>
<body>
<h1>Namespace for LoST server synchronization</h1>
<h2>urn:ietf:params:xml:ns:lostsync1</h2>
<p>See <a href="[URL of published RFC]">RFC 6739
</a>.</p>
</body>
</html>
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 Synchronization Namespace</title>
</head>
<body>
<h1>Namespace for LoST server synchronization</h1>
<h2>urn:ietf:params:xml:ns:lostsync1</h2>
<p>See <a href="[URL of published RFC]">RFC 6739
</a>.</p>
</body>
</html>
END
终止
Robins George, Cullen Jennings, Karl Heinz Wolf, Richard Barnes, Mayutan Arumaithurai, Alexander Mayrhofer, and Andrew Newton provided helpful input. Jari Urpalainen assisted with the RELAX NG schema. We would also like to thank our document shepherd Roger Marshall for his help with the document.
罗宾斯·乔治、卡伦·詹宁斯、卡尔·海因茨·沃尔夫、理查德·巴恩斯、马尤坦·阿鲁迈图赖、亚历山大·梅尔霍夫和安德鲁·牛顿提供了有益的意见。Jari Urpalainen协助了RELAX NG模式。我们还要感谢我们的文件守护人罗杰·马歇尔对文件的帮助。
We would like to particularly thank Andrew Newton for his timely and valuable review of the XML-related content.
我们要特别感谢Andrew Newton对XML相关内容的及时而有价值的评论。
We would like to thank Robert Sparks, Barry Leiba, Stephen Farrell, Brian Haberman, Pete Resnick, and Sean Turner for their AD reviews. We would also like to thank Bjoern Hoehrmann for his media type review, Julian Reschke and Martin Duerst for their applications area reviews, and Wassim Haddad for his Gen-ART review.
我们要感谢罗伯特·斯帕克斯、巴里·莱巴、斯蒂芬·法雷尔、布赖恩·哈伯曼、皮特·雷斯尼克和肖恩·特纳的广告评论。我们还要感谢比约恩·霍尔曼（Bjoern Hoehrmann）的媒体类型评论，朱利安·雷什克（Julian Reschke）和马丁·杜尔斯特（Martin Duerst）的应用领域评论，以及瓦西姆·哈达德（Wassim Haddad）的当代艺术评论。
[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月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[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月。
[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] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T. Roessler, "XML-Signature Syntax and Processing", World Wide Web Consortium, Second Edition, REC-xmldsig-core-20020212, June 2008.
[W3C.REC-xmldsig-core-20020212]伊斯特莱克，雷格尔，J.，索洛，D.，赫希，F.，和T.罗斯勒，“XML签名语法和处理”，万维网联盟，第二版，REC-xmldsig-core-20020212，2008年6月。
[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月。
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009.
[RFC5582]Schulzrinne，H.，“位置到URL映射体系结构和框架”，RFC5822009年9月。
Authors' Addresses
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼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@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at