[要約] RFC 6739は、LoSTプロトコルに基づいてサービスの境界と<マッピング>要素を同期するためのものです。その目的は、位置情報をサービスに変換するための標準的な方法を提供することです。
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.
Location-to-Service Translation（LoST）プロトコルは、サービス識別子と測地または市民の位置情報をサービスURIとサービス境界にマッピングするためのXMLベースのプロトコルです。特に、緊急サービスの場所に適した公共安全応答ポイント（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プロトコル仕様の<mapping>要素は、サービスの境界に関する情報をカプセル化し、すべての場所が同じサービスのURI（Uniform Resource Identifier）または特定のサービスの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.
このドキュメントでは、2つのノード間でこれらのマッピングを交換するためのXMLプロトコルを定義しています。このメカニズムは、2つのエンティティ間で信頼できる<mapping>要素を交換するために設計されています。キャッシュされた<mapping>要素、つまり権限のない要素を交換することは可能ですが、想定されていません。 <mapping>要素の形式はLoST仕様から再利用されていますが、このドキュメントのメカニズムは、LoSTプロトコルがなくても使用できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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は1つ以上のサービス境界を開示するため、この情報を使用して適切な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ベースのプロトコルを定義して、2つのエンティティ、つまりLoST同期ソースとLoST同期宛先の間で信頼できるサービス境界を交換します。このプロトコルは、サービス境界情報のクエリにLoSTプロトコルが使用されているかどうかに関係なく使用できます。
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は、LoSTプロトコルの使用例から始まります。セクション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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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.
このドキュメント全体で、「LoST同期ソース」および「LoST同期宛先」という用語を使用して、交換のプロトコルエンドポイントを示します。このプロトコルは、本文では「LoST Sync」と呼ばれています。
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.
LoST同期メカニズムは、たとえば、[RFC5582]で指定されているように、LoSTアーキテクチャで使用できます。そこでは、LoSTサーバーが協力して、ユビキタスでグローバルにスケーラブルで復元力のあるマッピングサービスを提供します。 LoSTマッピングアーキテクチャでは、LoSTサーバーはピアリング、つまり進行中のデータ交換関係を持つことができます。ピアリング関係は、ローカルポリシーに基づいて手動で設定されます。 LoSTサーバーは、他の任意の数のLoSTサーバーとピアリングできます。フォレストガイドは他のフォレストガイドとピアリングします。信頼できるマッピングサーバーは、同じクラスター内、またはツリー内のそれらの上または下にあるフォレストガイドおよび他の信頼できるサーバーとピアリングします。信頼できるマッピングサーバーは、カバレッジ領域をツリーの「上」に、つまり子ノードから親ノードにプッシュします。子供は、地理空間または市民の地域の親に、特定のサービスの対象であることを知らせます。
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.
オーストリアとフィンランドなど、2か国でのLoSTの架空の配備について考えます。私たちの例では、オーストリアは「東」、「西」、「ウィーン」というラベルの付いた3つの信頼できるマッピングサーバーを実行しています。前者の2つは、ウィーンを除いて国全体をカバーしています。 ISP、大学、および音声サービスプロバイダー（VSP）によって実行される他のキャッシュLoSTサーバーが存在する場合がありますが、これらはこの図には関係ありません。一方、フィンランドは、フォレストガイドとしても機能する単一のLoSTサーバーのみを展開することを決定しました。この単純化した図では、1つのサービス、つまり「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' | \\----//
\\----//
Figure 1: LoST Deployment Example
図1：LoSTの導入例
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).
フォレストガイドオーストリア：このフォレストガイドには、3つの信頼できるマッピングサーバー（東、西、およびウィーン）のマッピングが含まれています。各マッピングにはサービスURNが含まれており、これらのマッピングはPSAPまたは緊急サービスルーティングプロキシ（ESRP）ではなくLoSTサーバーを指していることに注意してください。
LoST Server 'East': This LoST server contains all the mappings to PSAPs covering the eastern part of the country.
LoSTサーバー「東」：このLoSTサーバーには、国の東部をカバーする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:
さらに、LoSTサーバーは、サーバーが持つすべての情報を集約し、特定のエリア（特定のサービスおよび特定の場所のプロファイル）を担当していることを示すフォレストガイドへの抽象ビューを提供します。この例では、マッピングの構造を以下に示します。
<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：フォレストガイドオーストリアマッピング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'属性はLoSTサーバー、つまり「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.
上記のマッピングは、オーストリアのフォレストガイドに提供するLoSTサーバー「east-austria.lost-example.com」です。
LoST Server 'West': This LoST server contains all the mappings to PSAPs covering the western half of the country.
LoSTサーバー「西」：このLoSTサーバーには、国の西半分をカバーするPSAPへのすべてのマッピングが含まれています。
LoST Server 'Vienna': This LoST server contains all the mappings to PSAPs for the city of Vienna.
LoSTサーバー「ウィーン」：このLoSTサーバーには、ウィーン市の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.
フォレストガイドフィンランド：この例では、フィンランドがIPベースの緊急サービスソリューションとして国全体に単一のESRPを展開していると想定しています。図1に示すように、LoSTサーバーは1つだけで、フォレストガイドと同じ場所に配置されます。このフォレストガイド（FG）がLoST Syncを介して配布するマッピングデータを図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>
Figure 3: Forest Guide Finland Mapping XML Snippet
図3：森林ガイドフィンランドマッピングXMLスニペット
An example mapping stored at the co-located LoST server is shown in Figure 4.
同じ場所にあるLoSTサーバーに保存されているマッピングの例を図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>
Figure 4: Forest Guide Finland / Co-Located LoST Server Mapping XML Snippet
図4：フォレストガイドフィンランド/同じ場所にあるLoSTサーバーマッピング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 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.
このドキュメントで説明するLoST同期メカニズムは、2つのフォレストガイド間で実行できます。これにより、FGオーストリアに保存されている3つのマッピングがFGフィンランドに送信され、FGフィンランドの1つのマッピングがFGオーストリアに送信されます。さらに、3つのオーストリアのLoSTサーバーは、LoST Syncを利用して、オーストリアのFGに境界を通知できます。オーストリアにあるこれら3つの信頼できるマッピングサーバーは、独自のマッピング情報を維持する責任があります。交換されるデータの量は少なく、予想される変更率は低いため、ノードは、変更が発生するたびにすべてのマッピング情報を常に交換するように構成されています。
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.
このドキュメントでは、2種類の交換を定義します。図5および6に示すように、2つのノード間の交換で最もよく説明されています。プロトコル交換は常にLoST同期ソースとLoST同期宛先の間で実行されます。図5および6の例のノードAには、ノードBが取得しようとしているマッピングがあります。ノードAはデータのソースとして機能し、ノードBは宛先です。
The <getMappingsRequest> request allows a LoST Sync source to request mappings from a LoST Sync destination.
<getMappingsRequest>リクエストにより、LoST SyncソースはLoST Sync宛先からのマッピングをリクエストできます。
+---------+ +---------+
| 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
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>交換により、LoST同期ソースがマッピングをLoST同期宛先にプッシュできます。この例では、ノード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> |
|<-----------------------------|
| |
| |
| |
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> Exchangeを使用したマッピングのクエリ
A LoST Sync destination has two ways to retrieve <mapping> elements from a LoST Sync source.
LoST同期の宛先には、LoST同期のソースから<mapping>要素を取得する2つの方法があります。
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. Lost Sync宛先にマッピングがない場合、図7に示すように、空の<getMappingsRequest>メッセージを送信します。これは、LoST同期ソースからすべてのマッピングを取得したいことを示しています。リクエストが他のノードにそれ以上伝播しないことに注意してください。
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. LoST Syncの宛先ノードが以前の交換ですでにマッピングを取得している場合は、これらのマッピングがその間に更新されたかどうかを確認する必要があります。更新されたマッピング情報をいつポーリングするかに関するポリシーは、このドキュメントの範囲外です。 <getMappingsRequest>メッセージに1つ以上の<exists>子要素が含まれている場合、ソースは宛先で欠落しているか、更新されているマッピングのみを返すことができます。
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>メッセージを発行した後、LoST同期宛先は<getMappingsResponse>メッセージを待ちます。応答が成功した場合、LoST同期宛先は受信したマッピングを保存し、どのマッピングを更新するかを決定します。
When a LoST Sync source receives an empty <getMappingsRequest> message, then all locally available mappings MUST be returned.
LoST同期ソースが空の<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.
LoST同期ソースは、1つ以上の<exists>子要素を含む<getMappingsRequest>メッセージを受信すると、ローカルマッピングデータベースに問い合わせて、クライアントのマッピングのいずれかが古くなっていないかどうか、およびマッピングがあるかどうかを判断する必要があります。ローカルではクライアントはまだ持っていません。前者は、より最近の「lastUpdated」日付のマッピングが存在する「source」および「sourceID」属性に対応するマッピングを見つけることによって決定できます。
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.
最初の例は、LoST Syncソースでローカルに保存されたすべてのマッピングを取得する空の<getMappingsRequest>メッセージを示しています。
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lostsync1"/>
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 = "authoritative.bar.example"、sourceId = "7e3f40b098c711dbb6060800200c9a66"、および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>
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= "authoritative.bar.example"およびsourceId = "7e3f40b098c711dbb6060800200c9a66"の識別により、より新しいマッピングが利用可能でした。ソースが "authoritative.foo.example"の、欠落しているマッピングが1つだけ見つかり、返されました。
<?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>
<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>
</sync:getMappingsResponse>
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.
LoST同期ソースが、そのピアが関心を持つ新しい情報を取得すると、新しいマッピングをピアにプッシュする場合があります。両方のピアの構成設定により、この機能を使用するかどうか、およびどのマッピングを他のどのピアにプッシュするかが決まります。新しいマッピングは、ローカルマッピングデータベースに手動で追加したり、他のエンティティと対話したりするなど、さまざまな方法で到着します。マッピングを削除すると、プロトコルの相互作用がトリガーされる場合もあります。
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.
LoST同期ソースは、<mapping>要素をプッシュしたLoST同期宛先を追跡する必要があります（SHOULD）。状態情報を保持しない場合は、常に完全なデータセットをプッシュする必要があります。 [RFC5222]のセクション5.1で説明したように、<mapping>要素は「source」、「sourceID」、および「lastUpdated」属性によって識別されます。これらの3つの属性が一致する場合、マッピングは同じと見なされます。
A <pushMappings> request sent by a LoST Sync source MUST contain one or more <mapping> elements.
LoST同期ソースから送信された<pushMappings>リクエストには、1つ以上の<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.
LoST同期の宛先が<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.
受信したマッピングが「source」と「sourceId」に基づく既存のマッピングと一致しない場合は、独立したマッピングとしてローカルキャッシュに追加する必要があります。
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'属性を含めることができます（MAY）。 <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に示します。次のように識別された2つの新しいマッピングを取得したLoSTノードを想像してください。
o source="authoritative.example" sourceId="7e3f40b098c711dbb6060800200c9a66" lastUpdated="2008-11-26T01:00:00Z"
o source = "authoritative.example" sourceId = "7e3f40b098c711dbb6060800200c9a66" lastUpdated = "2008-11-26T01：00：00Z"
o source="authoritative.example" sourceId="7e3f40b098c711dbb606011111111111" lastUpdated="2008-11-01T01:00:00Z"
o source = "authoritative.example" sourceId = "7e3f40b098c711dbb606011111111111" lastUpdated = "2008-11-01T01：00：00Z"
These two mappings have to be added to the peer's mapping database.
これら2つのマッピングは、ピアのマッピングデータベースに追加する必要があります。
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">
<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 source="nj.us.example"
sourceId="123"
lastUpdated="2008-11-01T01:00:00Z"
expires="2008-11-01T01:00:00Z"/>
</sync:pushMappings>
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" />
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">
<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>
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.
LoST同期では、要求と応答を伝送するための基本的なプロトコル転送メカニズムが必要です。このドキュメントは、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]を使用する場合、LoST SyncメッセージはPOSTメソッドを使用します。リクエストは、Cache-Control応答ディレクティブ「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.
LoST警告またはエラーを示すものを含むすべてのLoST Sync応答は、2xx応答、通常は200（OK）で送信されます。 3xx、4xx、および5xx HTTP応答コードは、要求自体が失敗したか、リダイレクトされたことを示します。これらの応答には、LoST Sync 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.
注：パターンの定義をXML次世代LoST標準言語（RELAX NG）スキーマ[RFC5222]からこのドキュメントにコピーしないようにするために、以下のRELAX NGスキーマに "lost.rng"（XML構文）として含めます。
<?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">
<include href="lost.rng"/>
<start combine="choice">
<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>
<define name="pushMappings">
<element name="pushMappings">
<oneOrMore>
<ref name="mapping"/>
</oneOrMore>
<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="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>
<!-- error messages -->
<define name="notDeleted">
<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.
3つ以上のLoSTサーバーがこのドキュメントで説明されているメカニズムを使用する場合は、ループを回避することが重要です。図13に示す3つのLoSTサーバーA、B、C（それぞれが同期ソースおよび同期宛先として機能する）の例は、課題をさらに詳しく示しています。 AとBは相互にデータを同期します。同じことが、AとC、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が新しいマッピングを追加するとします。このマッピングは、「source」、「sourceid」、および「last updated」の組み合わせによって一意に識別されます。 Aがこの新しいマッピングをBとCにプッシュしたいとします。Bがこの新しいマッピングを取得すると、BはピアCに配信する必要があると判断します。CはマッピングをピアBにも配信する必要があります。元のマッピングが「source」、「sourceid」、および「last updated」がBまたはCによって変更されていない場合、これらの2つのサーバーはすでにマッピングを所有していることを認識し、更新を無視できます。
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 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.
実装は、受け取ったマッピングを変更してはなりません。ただし、悪意を持って行動するエンティティは、意図的にマッピングを変更したり、偽のマッピングを挿入したりします。信頼できないメンバーが許可されていないカバレッジ領域を要求する可能性を回避するために、信頼できるマッピングサーバーは、XMLデジタル署名[W3C.REC-xmldsig-core-20020212]を使用して、配布するマッピングに署名する必要があります。受信者は、署名エンティティが実際にその地域で話すことを許可されていることを確認する必要があります。多くの場合、これには、特定のエンティティがこの役割を引き受けることに同意するために、帯域外契約を締結する必要があります。マッピングアーキテクチャの参加者が信頼できる承認エンティティの小さなセットがない限り、特定の地域で発言できる人物を決定することは本質的に困難です。既存のカバレッジ領域が、<uri>要素に異なる値を含む新しいカバレッジ領域に置き換えられた場合、受信システムは特に疑わしいはずです。マッピングがデジタル署名されている場合、中間のLoSTサーバーによってマッピングを変更することはできません。
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.
このドキュメントでは、2つのエンティティ間で信頼できるマッピング情報を交換するためのプロトコルを定義しています。したがって、このドキュメントで説明するプロトコル操作には、隣接ノードの認証が必要です。
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.
LoST同期クライアントとサーバーは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>要素の配布前にアクセス制御を実施したい場合を除き、LoST同期ソースとLoST同期宛先間の相互認証は、必ずしもすべての展開で必要なわけではありません。これは、たとえば、特定の緊急サービスネットワークが公共の配布用ではない内部マッピングを配布する場合に当てはまることがあります。
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.
追加の脅威は、LoSTサーバーが危険にさらされているか、正しく設定されていないことが原因です。サービス拒否は、挿入されたマッピングの結果である可能性があります。マッピングデータに存在しない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
オプションのパラメーター：charset
Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023].
RFC 3023 [RFC3023]で指定されているapplication / xmlのcharsetパラメータと同じです。
Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], Section 3.2.
エンコーディングに関する考慮事項：[RFC3023]のセクション3.2で説明されている「application / 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.
セキュリティに関する考慮事項：このコンテンツタイプはLoST同期プロトコルペイロードを伝送するように設計されており、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ファイルタイプコード： 'TEXT'
Person & email address to contact for further information:
Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Intended usage: LIMITED USE Restrictions on usage: None
使用目的：LIMITED USE使用制限：なし
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 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
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.
RELAX NGスキーマ：登録済みのRELAX NGスキーマは、セクション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
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>
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スキーマを支援しました。また、ドキュメントシェパードのRoger Marshallがドキュメントを手伝ってくれたことにも感謝します。
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.
ADのレビューを提供してくれたRobert Sparks、Barry Leiba、Stephen Farrell、Brian Haberman、Pete Resnick、およびSean Turnerに感謝します。また、メディアタイプのレビューについてはBjoern Hoehrmannに、アプリケーション領域のレビューについてはJulian ReschkeとMartin Duerst、そしてGen-ARTレビューについては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、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、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 Media Types」、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、「Media Type Specifications and Registration Procedures」、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、「LoST：A Location-to-Service Translation Protocol」、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、「The Transport Layer Security（TLS）Protocol Version 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] Eastlake、D.、Reagle、J.、Solo、D.、Hirsch、F。、およびT. Roessler、「XML-Signature Syntax and Processing」、World Wide Web Consortium、第2版、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。、「Location-to-URL Mapping Architecture and Framework」、RFC 5582、2009年9月。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
ヘニングシュルズリンネコロンビア大学コンピュータサイエンス学科450コンピュータサイエンスビルディングニューヨーク、ニューヨーク10027アメリカ
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 Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at