[要約] RFC 7840は、HELDプロトコルのためのルーティングリクエスト拡張に関するものであり、位置情報の配信におけるHTTPの利用をサポートします。このRFCの目的は、HELDプロトコルを使用して位置情報を要求する際に、より効率的なルーティングを実現することです。
Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 7840 Winterb Consulting Services
Updates: 5985, 6881 H. Tschofenig
Category: Standards Track
ISSN: 2070-1721 L. Liess
Deutsche Telekom
May 2016
A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol
HTTP対応Location Delivery（HELD）プロトコルのルーティング要求拡張
Abstract
概要
For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function. Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations.
ロケーションサーバーが緊急ルーティング情報にアクセスできる場合、ロケーション要求に必要なルーティング情報の要求が含まれていれば、ロケーションサーバーはルーティング情報をロケーション情報とともに返すことができます。このドキュメントでは、この機能をサポートするようにRFC 5985を更新するHTTP対応ロケーション配信（HELD）プロトコルの拡張について説明します。現在の位置の取得とルート決定の手順は別々の操作であるため、単一の要求応答交換で位置とルーティング情報を取得できるようにすると、RFC 6881が更新されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7840.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7840で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7
6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13
10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
The general Emergency Context Resolution with Internet Technology (ECRIT) calling models described in [RFC6443] and [RFC6881] require a local Location-to-Service Translation (LoST) server or network of forest guides in order to determine the address of the Public Safety Answering Point (PSAP) in the best position to handle a call. Networks of forest guides have not materialized and while PSAPs are moving towards IP networks, LoST server deployment is not ubiquitous. Some regions and countries have expressed reluctance to deploy LoST servers making aspects of the current ECRIT architecture hard to realize.
[RFC6443]および[RFC6881]で説明されているインターネット技術（ECRIT）呼び出しモデルを使用した一般的な緊急コンテキスト解決では、Public Safetyのアドレスを決定するために、ローカルのLocation-to-Service Translation（LoST）サーバーまたはフォレストガイドのネットワークが必要です。通話を処理するのに最適な位置に留守番電話（PSAP）。フォレストガイドのネットワークは具体化されておらず、PSAPがIPネットワークに移行している間、LoSTサーバーの展開はユビキタスではありません。一部の地域や国では、LoSTサーバーを展開することに抵抗を示し、現在のECRITアーキテクチャの側面を実現することを困難にしています。
To address regulatory requirements, such as [M493], evolving architectures in Europe couple location and routing information in the access network while using a softswitch-centric approach to emergency call processing. This document describes an extension to the HELD protocol [RFC5985], so that a location information server can provide emergency routing information in the absence of a LoST server or network of forest guides.
[M493]などの規制要件に対処するために、ヨーロッパの進化するアーキテクチャは、緊急呼処理にソフトスイッチ中心のアプローチを使用しながら、アクセスネットワーク内のロケーションとルーティング情報を結合します。このドキュメントでは、HELDプロトコル[RFC5985]の拡張について説明します。これにより、位置情報サーバーは、LoSTサーバーまたはフォレストガイドのネットワークがなくても緊急ルーティング情報を提供できます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The terms "Location Information Server (LIS)", "Emergency Services Routing Proxy (ESRP)", "Voice Service Provider (VSP)", and "Public Safety Answering Point (PSAP)" are used as defined in [RFC6443].
[Location Information Server（LIS）]、[Emergency Services Routing Proxy（ESRP）]、[Voice Service Provider（VSP）]、および[Public Safety Answering Point（PSAP）]という用語は、[RFC6443]での定義に従って使用されます。
The term "Access Network Provider" is used as defined in [RFC5687] and encompasses both the Internet Access Provider (IAP) and Internet Service Provider (ISP).
「アクセスネットワークプロバイダー」という用語は、[RFC5687]で定義されているように使用され、インターネットアクセスプロバイダー（IAP）とインターネットサービスプロバイダー（ISP）の両方を含みます。
The term "forest guide" is used as defined in [RFC5582].
「フォレストガイド」という用語は、[RFC5582]で定義されているとおりに使用されます。
The Internet emergency calling architecture specified in [RFC6881] describes two main models for emergency call processing. The first is a device-centric model, where a device obtains location information using a location configuration protocol, such as HELD [RFC5985], and then proceeds to determine the address of the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this model in a simplified form.
[RFC6881]で指定されているインターネット緊急通報アーキテクチャは、緊急通報処理の2つの主要なモデルについて説明しています。 1つ目はデバイス中心のモデルであり、デバイスはHELD [RFC5985]などのロケーション構成プロトコルを使用してロケーション情報を取得し、LoST [RFC5222]を使用してローカルPSAPに近い次のホップのアドレスを決定します。図1は、このモデルを簡略化した形式で示しています。
+---Location Request---+
| (1) |
+---+----+ +---V---+
| |<--Location--| LIS |
| Caller | (2) +-------+ +--------+
| | | ESRP/ |
| |----Find Service-------+ | PSAP |
+------^-+ (3) | +--------+
| | +--------V----+ ^
| +-----Service----| LoST Server | |
| (4) +-------------+ +---+---+
+-------------Call Initiation------------>| VSP |
(5) +-------+
Figure 1: Device-Centric Emergency Services Model
図1：デバイス中心の緊急サービスモデル
The second approach is a softswitch-centric model, where a device initiates an emergency call, and the serving softswitch detects that the call is an emergency and initiates retrieving the caller's location from a LIS using HELD [RFC5985] with identity extensions [RFC6155] [RFC6915] and then determines the route to the local PSAP using LoST [RFC5222]. Figure 2 shows the high-level protocol interactions.
2番目のアプローチは、ソフトスイッチ中心のモデルで、デバイスが緊急コールを開始し、サービングソフトスイッチがそのコールが緊急であることを検出し、IDLD [RFC6155]を使用してHELD [RFC5985]を使用するLISから発信者の場所の取得を開始します。 RFC6915]を実行し、LoST [RFC5222]を使用してローカルPSAPへのルートを決定します。図2は、高レベルのプロトコル相互作用を示しています。
+---Location Request---+
| (2) |
+---V---+ |
| LIS | |
+----+--+ +----+----+
| | |
+----Location--->| Soft- |
+--------+ (3) | switch |
| Caller |------Call Initiation------------> | |
+--------+ (1) +-+-^---+-+
+-------------+ | | |
| LoST Server |<-Find Service--+ | |
+------+------+ (4) | |
| | |
+----------Service--------+ |
(5) |
+-----------+ |
| ESRP/PSAP |<------Call----+
+-----------+ (6)
Figure 2: Softswitch-Centric Calling Model
図2：ソフトスイッチ中心の呼び出しモデル
In the softswitch-centric model, when a VSP receives an emergency call, it performs two tasks. The first task is to determine the correct LIS to ask for location information; this is done using a combination of reverse DNS lookup described in [RFC7216] to acquire the serving domain name and then using [RFC5986] to determine the LIS URI. Once the location is obtained from the LIS, the VSP determines the LoST server associated with the domain serving the caller and queries it for the correct PSAP address.
ソフトスイッチ中心のモデルでは、VSPが緊急コールを受信すると、2つのタスクを実行します。最初のタスクは、位置情報を要求する正しいLISを決定することです。これは、[RFC7216]で説明されている逆DNSルックアップを組み合わせて使用してドメイン名を取得し、次に[RFC5986]を使用してLIS URIを決定します。 LISから場所が取得されると、VSPは発信者にサービスを提供するドメインに関連付けられているLoSTサーバーを特定し、正しいPSAPアドレスを照会します。
LoST server discovery is a domain-based activity, similar to the LIS discovery technique. However, unlike the LIS that is a domain-bound service, a LoST server is a geographically bound service. This means that for a domain that spans multiple geographic regions, the LoST server determined may not be able to provide a route to the necessary PSAP. When this occurs, the contacted LoST server invokes the help of other LoST servers, and this requires the deployment of forest guides.
LoSTサーバーディスカバリは、ドメインベースのアクティビティであり、LISディスカバリテクニックに似ています。ただし、ドメインにバインドされたサービスであるLISとは異なり、LoSTサーバーは地理的にバインドされたサービスです。つまり、複数の地域にまたがるドメインの場合、決定されたLoSTサーバーは、必要なPSAPへのルートを提供できない可能性があります。これが発生すると、接続されたLoSTサーバーが他のLoSTサーバーのヘルプを呼び出すため、フォレストガイドを展開する必要があります。
At the time of writing, several countries have expressed a reluctance to deploy public LoST servers. In countries amenable to the use of LoST and forest guides, no public forest guides have been deployed. There appears to be little interest from the public sector in establishing a global forest-guide network. These issues pose threats to the ability of both the device-centric and the softswitch-centric calling approaches to operate everywhere.
これを書いている時点で、いくつかの国は公共のLoSTサーバーを展開することに消極的です。 LoSTとフォレストガイドの使用が可能な国では、パブリックフォレストガイドは配置されていません。グローバルな森林ガイドネットワークの確立には、公共部門の関心はほとんどないようです。これらの問題は、デバイス中心のコールアプローチとソフトスイッチ中心のコールアプローチの両方がどこでも動作する能力に脅威をもたらします。
The device-centric and softswitch-centric calling models both involve the notion of a LIS bound to the serving access network. In many cases, the LIS already knows the destination PSAP URI for any given location. In [RFC6881], for example, the LIS validates civic locations using a location validation procedure based on the LoST protocol [RFC5222]. The LoST validation request is similar to a LoST routing request and provides the LIS with the same PSAP routing information that a routing request would. In other cases, the LIS knows the correct PSAP for a given location at provisioning time, or the access network might always route to the same emergency provider. Irrespective of the way in which the LIS learns the PSAP URI for a location, the LIS will, in a great many cases, already have this information.
デバイス中心のモデルとソフトスイッチ中心の呼び出しモデルのどちらにも、サービスを提供するアクセスネットワークにバインドされたLISの概念が含まれます。多くの場合、LISは特定の場所の宛先PSAP URIをすでに認識しています。たとえば、[RFC6881]では、LISは、LoSTプロトコル[RFC5222]に基づく位置検証手順を使用して、市民の位置を検証します。 LoST検証要求はLoSTルーティング要求に似ており、ルーティング要求と同じPSAPルーティング情報をLISに提供します。その他の場合、LISはプロビジョニング時に特定の場所の正しいPSAPを知っているか、アクセスネットワークが常に同じ緊急プロバイダーにルーティングされる場合があります。 LISが場所のPSAP URIを学習する方法に関係なく、LISは、多くの場合、すでにこの情報を持っています。
This document specifies an extension to the HELD protocol, so that emergency routing information can be requested from the LIS at the same time that location information is requested. This document updates [RFC6881] by requiring devices and softswitches that understand this specification to always request routing information to avoid the risk of query failure where no LoST server or forest-guide network is deployed.
このドキュメントでは、HELDプロトコルの拡張を指定しているため、ロケーション情報が要求されると同時にLISから緊急ルーティング情報を要求できます。このドキュメントは、この仕様を理解するデバイスとソフトスイッチが常にルーティング情報を要求し、LoSTサーバーまたはフォレストガイドネットワークが展開されていない場合のクエリ失敗のリスクを回避することを要求することにより、[RFC6881]を更新します。
The LoST protocol [RFC5222] defines a <mapping> element that describes a service region and associated service URLs. Reusing this element from LoST to provide the routing URIs was considered. However, this would have meant that several of the mandatory components in the <mapping> element would have had to contain ambiguous or misleading values. Specifically, the "source" attribute is required to contain a LoST application-unique string for the authoritative server. However, in the situations described in this specification, there may not be an authoritative LoST server, so any value put into this attribute would be misleading. In addition to this, routing information received in the manner described in this specification should not be cached by the receiver, so detailing when the routing information expires or was last updated is irrelevant.
LoSTプロトコル[RFC5222]は、サービスリージョンと関連するサービスURLを記述する<mapping>要素を定義します。 LoSTからこの要素を再利用してルーティングURIを提供することを検討しました。ただし、これは<mapping>要素の必須コンポーネントのいくつかに、あいまいな値または誤解を招く値を含める必要があったことを意味します。具体的には、「source」属性には、権限のあるサーバーのLoSTアプリケーション固有の文字列を含める必要があります。ただし、この仕様で説明されている状況では、信頼できるLoSTサーバーがない可能性があるため、この属性に値を設定すると誤解を招く可能性があります。これに加えて、この仕様で説明されている方法で受信されたルーティング情報は受信者によってキャッシュされるべきではないので、ルーティング情報が期限切れになるか、最後に更新されたときの詳細は関係ありません。
The mechanism consists of adding an element to the HELD locationRequest and an element to the locationResponse.
このメカニズムは、HELD locationRequestに要素を追加し、locationResponseに要素を追加することで構成されます。
The request element indicates that the requestor wants the LIS to provide routing information based on the location of the end device. If the routing request is sent with no attribute, then URIs for urn:service:sos are returned. If the requestor wants routing information for a specific service, then they may include an optional service URN. This service MUST exist in the IANA "Service URN Labels" repository created by [RFC5031]. If a service is specified, and the LIS does not understand the requested service, then URIs for urn:service:sos are returned.
request要素は、リクエスタがLISにエンドデバイスの場所に基づいてルーティング情報を提供することを望んでいることを示します。ルーティング要求が属性なしで送信された場合、urn：service：sosのURIが返されます。リクエスタが特定のサービスのルーティング情報を必要とする場合、オプションのサービスURNを含めることができます。このサービスは、[RFC5031]によって作成されたIANA "Service URN Labels"リポジトリに存在する必要があります。サービスが指定されていて、LISが要求されたサービスを理解していない場合、urn：service：sosのURIが返されます。
If the LIS understands the routing request and has routing information for the location, then it includes the information in a routingInformation element returned in the locationResponse. How the LIS obtains this information is left to implementation. Possibilities are described in Section 3.
LISがルーティング要求を理解し、場所のルーティング情報を持っている場合は、locationResponseで返されるroutingInformation要素に情報が含まれます。 LISがこの情報を取得する方法は、実装に任されています。可能性については、セクション3で説明します。
A LIS that does not understand the routing request element ignores it and returns the location information in the normal manner.
ルーティング要求要素を理解しないLISはそれを無視し、通常の方法で位置情報を返します。
A LIS that does support the routing request element MUST support returning URIs for urn:service:sos and any regionally defined sub-services while following the URN traversal rules defined in [RFC5031].
ルーティングリクエストエレメントをサポートするLISは、[RFC5031]で定義されているURNトラバーサルルールに従って、urn：service：sosおよびリージョンで定義されたサブサービスのURIを返す必要があります。
A LIS that does understand the routing request element but can't obtain any routing information for the end-device's location MUST set the defaultRoute attribute to "true" and return a default PSAP or gateway URI along with the determined location information in the locationResponse.
ルーティング要求要素を理解しているが、エンドデバイスのロケーションのルーティング情報を取得できないLISは、defaultRoute属性を「true」に設定し、locationResponseで決定されたロケーション情報とともにデフォルトのPSAPまたはゲートウェイURIを返す必要があります。
A LIS that understands the routing request element but not the specified service URN MUST follow the URN traversal rules defined in [RFC5031].
ルーティング要求要素を理解するが、指定されたサービスURNを理解しないLISは、[RFC5031]で定義されているURNトラバーサルルールに従う必要があります。
A LIS that receives a request for emergency routing information that it understands MUST return the correct emergency routing information if it has or is able to acquire the routing information for the location of the target device.
理解している緊急ルーティング情報の要求を受け取ったLISは、ターゲットデバイスの場所のルーティング情報を持っているか、または取得できる場合、正しい緊急ルーティング情報を返さなければなりません（MUST）。
The routing information in the location response consists of a service element identified by a service name. The service name is a URN and might contain a general emergency service URN such as urn:service:sos or a specific service URN depending on what was requested and what the LIS is able to provide. A list of one or more service destinations is provided for the service name. Each destination is expressed as a URI, and each URI scheme should only appear once in this list. The routing URIs are intended to be used at the time they are received. To avoid any risks of using stale routing URIs, the values MUST NOT be cached by the receiving entity.
ロケーション応答のルーティング情報は、サービス名で識別されるサービス要素で構成されています。サービス名はURNであり、要求された内容とLISが提供できる内容に応じて、urn：service：sosなどの一般的な緊急サービスURNまたは特定のサービスURNが含まれる場合があります。サービス名には、1つ以上のサービス宛先のリストが提供されます。各宛先はURIとして表現され、各URIスキームはこのリストに1回だけ表示されます。ルーティングURIは、受信時に使用することを目的としています。古いルーティングURIを使用するリスクを回避するために、値は受信エンティティによってキャッシュされてはなりません（MUST NOT）。
This section describes the normative updates to Phone BCP [RFC6881].
このセクションでは、電話BCP [RFC6881]の規範的な更新について説明します。
It is important for devices and intermediaries to take all steps possible to ensure that emergency calls are routed to the correct PSAP. An alternative to providing routing information via global forest guides or local LoST servers is for local networks to configure the PSAP address information in the network location server. This specification updates Phone BCP [RFC6881] to provide this option. The update requires devices and intermediaries using the HELD protocol to always include the HELD routing extension. If the LIS is configured with the routing information, it can provide it; if it is not, then the device or intermediary tries LoST to acquire the PSAP URI.
デバイスと仲介者が可能なすべての手順を実行して、緊急コールが正しいPSAPに確実にルーティングされるようにすることが重要です。グローバルフォレストガイドまたはローカルLoSTサーバーを介してルーティング情報を提供する代わりに、ローカルネットワークがネットワークロケーションサーバーでPSAPアドレス情報を構成できます。この仕様は、このオプションを提供するためにPhone BCP [RFC6881]を更新します。この更新では、HELDプロトコルを使用するデバイスと仲介者が常にHELDルーティング拡張機能を含める必要があります。 LISがルーティング情報を使用して構成されている場合は、それを提供できます。そうでない場合、デバイスまたは仲介者はLoSTを試行してPSAP URIを取得します。
Section 6.5 of [RFC6881] defines "End System Location Configuration". Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the Location Configuration Protocol (LCP) such that "the request MUST include the requestRoutingInformation element." The remainder of the requirement remains unchanged.
[RFC6881]のセクション6.5は、「End System Location Configuration」を定義しています。要件ED-23 / INT-18 / SP-14は、HELDがLocation Configuration Protocol（LCP）として使用される場合に更新され、「リクエストにはrequestRoutingInformation要素が含まれている必要があります」。残りの要件は変更されていません。
This document adds a new requirement to Section 7 of [RFC6881].
このドキュメントは、[RFC6881]のセクション7に新しい要件を追加します。
"ED-51a : Endpoints MUST support the HELD requestRoutingInformation element and be able to interpret and use any routing information returned in the locationResponse."
「ED-51a：エンドポイントはHELD requestRoutingInformation要素をサポートし、locationResponseに返されるルーティング情報を解釈して使用できる必要があります。」
This document adds two new requirements to Section 8 of [RFC6881].
このドキュメントは、[RFC6881]のセクション8に2つの新しい要件を追加します。
"ED-52a : Endpoints that acquire routing information in a HELD locationResponse SHOULD use this routing information but MAY perform a LoST findService request if they have a location value."
「ED-52a：HELD locationResponseでルーティング情報を取得するエンドポイントはこのルーティング情報を使用する必要があります（SHOULD）が、ロケーション値がある場合は、LoST findServiceリクエストを実行できます（MAY）。
"ED-52b : Endpoints that acquire routing information in a HELD locationResponse with a defaultRoute attribute of "true" MUST perform a LoST findService request if they have a location value. If a route is provided by the LoST server, then this route MUST be used, otherwise the routing information provided in the HELD response SHOULD be used."
「ED-52b：デフォルトのルート属性が「true」であるHELD locationResponseでルーティング情報を取得するエンドポイントは、位置の値がある場合、LoST findServiceリクエストを実行する必要があります。LoSTサーバーによってルートが提供される場合、このルートはそれ以外の場合は、HELD応答で提供されるルーティング情報を使用する必要があります。」
This document amends SP-26 from Section 8 of [RFC6881] such that a LoST mapping need not be requested if non-default routing information is provided in the HELD locationResponse.
このドキュメントは、[RFC6881]のセクション8のSP-26を修正し、デフォルト以外のルーティング情報がHELD locationResponseで提供されている場合、LoSTマッピングを要求する必要がないようにしています。
This section describes the schema extension to HELD.
このセクションでは、HELDのスキーマ拡張について説明します。
<?xml version="1.0"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:ri"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ri="urn:ietf:params:xml:ns:geopriv:held:ri"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="requestRoutingInformation">
<xs:complexType name="empty">
<xs:attribute name="service" type="xs:anyUri"
use="optional" default="urn:service:sos"/>
</xs:complexType>
</xs:element>
<xs:complexType name="service">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="dest" type="xs:anyURI"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="defaultRoute" type="xs:boolean"
use="optional" default="false"/>
<xs:attribute name="serviceUri" type="xs:anyURI"
use="required"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="routingInformation" type="ri:riType"/>
<xs:complexType name="riType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="service" type="ri:service"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
Figure 3 illustrates a <locationRequest> example that contains IP flow information in the request.
図3は、リクエストにIPフロー情報を含む<locationRequest>の例を示しています。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="emergencyRouting">
<requestRoutingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/>
<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
layer4="tcp" layer3="ipv4">
<src>
<address>192.0.2.12</address>
<port>1024</port>
</src>
<dst>
<address>192.0.2.195</address>
<port>80</port>
</dst>
</flow>
</locationRequest>
Figure 3: Example Location Request
図3：ロケーション要求の例
Figure 4 illustrates the <locationResponse> message containing two location URIs: an HTTPS and a SIP URI. Additionally, the response contains routing information.
図4は、HTTPSとSIP URIの2つのロケーションURIを含む<locationResponse>メッセージを示しています。さらに、応答にはルーティング情報が含まれます。
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI>
</locationUriSet>
<routingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
<service serviceUri="urn:service:sos">
<dest>sip:112@example.com</dest>
<dest>sips:112@example.com</dest>
<dest>xmpp:112@example.com</dest>
</service>
</routingInformation>
</locationResponse>
Figure 4: Example Location Response
図4：ロケーション応答の例
Figure 5 illustrates the <locationResponse> message containing default routing information and an HTTPS location URI.
図5は、デフォルトのルーティング情報とHTTPSロケーションURIを含む<locationResponse>メッセージを示しています。
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2016-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
</locationUriSet>
<routingInformation
xmlns="urn:ietf:params:xml:ns:geopriv:held:ri">
<service defaultRoute="true" serviceUri="urn:service:sos">
<dest>sip:112@example.com</dest>
<dest>sips:112@example.com</dest>
<dest>xmpp:112@example.com</dest>
</service>
</routingInformation>
</locationResponse>
Figure 5: Example Location Response with Default Routing Information
図5：デフォルトのルーティング情報を含むロケーション応答の例
This document makes no changes that require privacy considerations beyond those already described in [RFC5985]. It does, however, extend those described in [RFC6155].
このドキュメントは、[RFC5985]ですでに説明されているものを超えてプライバシーの考慮を必要とする変更を加えません。ただし、[RFC6155]で説明されているものを拡張します。
[RFC5985] describes the privacy considerations surrounding the HELD location configuration protocol, and this document makes no specific changes to these considerations.
[RFC5985]は、HELDロケーション設定プロトコルを取り巻くプライバシーの考慮事項を説明しており、このドキュメントでは、これらの考慮事項に特定の変更を加えていません。
[RFC6155] extends HELD beyond a simple LCP by enabling authorized third parties to acquire location information and describing the issues in Section 4. The HELD routing extension supports returning URIs that represent specific services operating in the Target's vicinity. This represents additional information about the Target; as a consequence, it is recommended that this option only be used when the LIS returns a location URI, not a location value.
[RFC6155]は、許可された第三者が位置情報を取得できるようにし、セクション4で問題を説明することにより、単純なLCPを超えてHELDを拡張します。これは、ターゲットに関する追加情報を表します。結果として、このオプションは、LISが場所の値ではなく場所のURIを返す場合にのみ使用することをお勧めします。
This document imposes no additional security considerations beyond those already described in [RFC5985] and [RFC6155].
このドキュメントは、[RFC5985]と[RFC6155]ですでに説明されているものを超える追加のセキュリティの考慮事項を課しません。
10.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:geopriv:held:ri'
Per this document, IANA has registered a new XML namespace, following the guidelines in [RFC3688].
このドキュメントに従って、IANAは[RFC3688]のガイドラインに従って、新しいXML名前空間を登録しました。
URI: urn:ietf:params:xml:ns:geopriv:held:ri
Registrant Contact: IETF ECRIT working group (ecrit@ietf.org), James Winterbottom (a.james.winterbottom@gmail.com).
登録者の連絡先：IETF ECRITワーキンググループ（ecrit@ietf.org）、James Winterbottom（a.james.winterbottom@gmail.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Routing Information Extensions</title>
</head>
<body>
<h1>Additional Element for HELD Routing Information</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:ri</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7840.txt">
RFC 7840</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順に従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:held:ri
Registrant Contact: IETF ECRIT working group (ecrit@ietf.org), James Winterbottom (a.james.winterbottom@gmail.com).
登録者の連絡先：IETF ECRITワーキンググループ（ecrit@ietf.org）、James Winterbottom（a.james.winterbottom@gmail.com）。
XML: The XML for this schema can be found as the entirety of Section 6 of this document.
XML：このスキーマのXMLは、このドキュメントのセクション6全体として見つかります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, DOI 10.17487/RFC5985, September 2010, <http://www.rfc-editor.org/info/rfc5985>.
[RFC5985] Barnes、M。、編、「HTTP対応ロケーション配信（HELD）」、RFC 5985、DOI 10.17487 / RFC5985、2010年9月、<http://www.rfc-editor.org/info/rfc5985> 。
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, <http://www.rfc-editor.org/info/rfc6881>.
[RFC6881]ローゼン、B。およびJ.ポーク、「緊急通話をサポートする通信サービスの現在のベストプラクティス」、BCP 181、RFC 6881、DOI 10.17487 / RFC6881、2013年3月、<http：//www.rfc-editor .org / info / rfc6881>。
[M493] European Telecommunications Standards Institute, "Functional architecture to support European requirements on emergency caller location determination and transport", ES 203 178, V1.1.1, February 2015.
[M493] European Telecommunications Standards Institute、「緊急発信者の場所の特定と転送に関するヨーロッパの要件をサポートする機能アーキテクチャ」、ES 203 178、V1.1.1、2015年2月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<http://www.rfc-editor.org/info/rfc3688>。
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, DOI 10.17487/RFC5031, January 2008, <http://www.rfc-editor.org/info/rfc5031>.
[RFC5031] Schulzrinne、H。、「緊急およびその他の既知のサービスのためのUniform Resource Name（URN）」、RFC 5031、DOI 10.17487 / RFC5031、2008年1月、<http://www.rfc-editor.org/ info / rfc5031>。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, <http://www.rfc-editor.org/info/rfc5222>.
[RFC5222] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「LoST：A Location-to-Service Translation Protocol」、RFC 5222、DOI 10.17487 / RFC5222、2008年8月、<http： //www.rfc-editor.org/info/rfc5222>。
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, DOI 10.17487/RFC5582, September 2009, <http://www.rfc-editor.org/info/rfc5582>.
[RFC5582] Schulzrinne、H。、「Location-to-URL Mapping Architecture and Framework」、RFC 5582、DOI 10.17487 / RFC5582、2009年9月、<http://www.rfc-editor.org/info/rfc5582>。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010, <http://www.rfc-editor.org/info/rfc5687>.
[RFC5687] Tschofenig、H。およびH. Schulzrinne、「GEOPRIV Layer 7 Location Configuration Protocol：Problem Statement and Requirements」、RFC 5687、DOI 10.17487 / RFC5687、March 2010、<http://www.rfc-editor.org/ info / rfc5687>。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, DOI 10.17487/RFC5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.
[RFC5986] Thomson、M。およびJ. Winterbottom、「Discovering the Local Location Information Server（LIS）」、RFC 5986、DOI 10.17487 / RFC5986、2010年9月、<http://www.rfc-editor.org/info/ rfc5986>。
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, DOI 10.17487/RFC6155, March 2011, <http://www.rfc-editor.org/info/rfc6155>.
[RFC6155] Winterbottom、J.、Thomson、M.、Tschofenig、H。、およびR. Barnes、「HTTP対応のロケーションデリバリ（HELD）でのデバイスIDの使用」、RFC 6155、DOI 10.17487 / RFC6155、2011年3月、 <http://www.rfc-editor.org/info/rfc6155>。
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 2011, <http://www.rfc-editor.org/info/rfc6443>.
[RFC6443] Rosen、B.、Schulzrinne、H.、Polk、J。、およびA. Newton、「インターネットマルチメディアを使用した緊急通話のフレームワーク」、RFC 6443、DOI 10.17487 / RFC6443、2011年12月、<http：// www .rfc-editor.org / info / rfc6443>。
[RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915, April 2013, <http://www.rfc-editor.org/info/rfc6915>.
[RFC6915] Bellis、R。、「HTTP対応のロケーション配信（HELD）のフローID拡張機能」、RFC 6915、DOI 10.17487 / RFC6915、2013年4月、<http://www.rfc-editor.org/info/rfc6915 >。
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS", RFC 7216, DOI 10.17487/RFC7216, April 2014, <http://www.rfc-editor.org/info/rfc7216>.
[RFC7216] Thomson、M。、およびR. Bellis、「IPアドレスと逆引きDNSを使用したロケーション情報サーバー（LIS）の発見」、RFC 7216、DOI 10.17487 / RFC7216、2014年4月、<http：//www.rfc-editor。 org / info / rfc7216>。
Acknowledgements
謝辞
We would like to thank Wilfried Lange for sharing his views with us. We would also like to thank Bruno Chatras for his early review comments and Keith Drage for his more detailed review. Thanks to Roger Marshall and Randy Gellens for their helpful suggestions.
Wilfried Lange氏の意見を共有してくれたことに感謝します。また、初期のレビューコメントについてBruno Chatrasに、より詳細なレビューを提供してくれたKeith Drageにも感謝します。 Roger MarshallとRandy Gellensの有益な提案に感謝します。
Authors' Addresses
著者のアドレス
James Winterbottom Winterb Consulting Services Gwynneville, NSW 2500 Australia
James Winterbottom Winterbコンサルティングサービスグウィンビル、ニューサウスウェールズ州2500オーストラリア
Phone: +61 448 266004
Email: a.james.winterbottom@gmail.com
Hannes Tschofenig Hall in Tirol 6060 Austria
Hannes Tschofenig Hall in Tirol 6060オーストリア
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Laura Liess Deutsche Telekom Networks Deutsche Telekom Allee 7 Darmstadt, Hessen 64295 Germany
Laura Liess Deutsche Telekom Networks Deutsche Telekom Allee 7ダルムシュタットヘッセン州ドイツ
Email: L.Liess@telekom.de
URI: http://www.telekom.de