[要約] RFC 5808は、位置情報を参照するためのメカニズムの要件を定義しています。このRFCの目的は、位置情報の参照方法を標準化し、異なるシステム間での位置情報の共有を容易にすることです。
Internet Engineering Task Force (IETF) R. Marshall, Ed.
Request for Comments: 5808 TCS
Category: Informational May 2010
ISSN: 2070-1721
Requirements for a Location-by-Reference Mechanism
場所ごとのメカニズムの要件
Abstract
概要
This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging.
このドキュメントは、用語を定義し、位置ユニフォームリソース識別子（URI）を使用して位置ごとのアプローチに関連する要件を提供し、シグナリングやその他のインターネットメッセージング内の位置情報を処理します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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/rfc5808.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5808で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................5
3. Overview of Location-by-Reference ...............................6
3.1. Location URI Usage .........................................7
3.2. Location URI Expiration ....................................8
3.3. Location URI Authorization .................................8
3.4. Location URI Construction ..................................9
4. High-Level Requirements .........................................9
4.1. Requirements for a Location Configuration Protocol .........9
4.2. Requirements for a Location Dereference Protocol ..........11
5. Security Considerations ........................................12
6. Acknowledgements ...............................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................13
All location-based services rely on ready access to location information. Location information can be used in either a direct, Location-by-Value (LbyV) approach or an indirect, Location-by-Reference (LbyR) approach.
すべてのロケーションベースのサービスは、位置情報へのすぐにアクセスすることに依存しています。位置情報は、直接的な場所（LBYV）アプローチまたは間接的な場所ごと（LBYR）アプローチのいずれかで使用できます。
For LbyV, location information is conveyed directly in the form of a Presence Information Data Format Location Object (PIDF-LO) [RFC4119]. Using LbyV might be either infeasible or undesirable in some circumstances. There are cases where LbyR is better able to address location requirements for a specific architecture or application. This document provides a list of requirements for use with the LbyR approach, and leaves the LbyV model explicitly out of scope.
LBYVの場合、位置情報は、存在情報データ形式の場所オブジェクト（PIDF-LO）[RFC4119]の形式で直接伝えられます。LBYVを使用することは、状況によっては実行不可または望ましくない場合があります。LBYRが特定のアーキテクチャまたはアプリケーションの場所の要件に適切に対処できる場合があります。このドキュメントは、LBYRアプローチで使用する要件のリストを提供し、LBYVモデルを明示的に範囲外にします。
As justification for an LbyR model, consider the circumstance that in some mobile networks it is not efficient for the end host to periodically query the Location Information Server (LIS) for up-to-date location information. This is especially the case when power availability is a constraint or when a location update is not immediately needed. Furthermore, the end host might want to delegate the task of retrieving and publishing location information to a third party, such as to a presence server. Additionally, in some deployments, the network operator may not want to make location information widely available. These kinds of location scenarios form the basis of motivation for the LbyR model.
LBYRモデルの正当化として、一部のモバイルネットワークでは、最終的な位置情報を最終ホストが定期的にロケーション情報サーバー（LIS）を定期的に照会することは効率的ではないという状況を考えてください。これは、電源の可用性が制約である場合、または場所の更新がすぐに必要でない場合に特に当てはまります。さらに、エンドホストは、位置情報を取得および公開するタスクを、プレゼンスサーバーなどの第三者に委任したい場合があります。さらに、一部の展開では、ネットワークオペレーターが位置情報を広く利用できるようにしたくない場合があります。これらの種類の位置シナリオは、LBYRモデルの動機付けの基礎を形成します。
The concept of an LbyR mechanism is simple. An LbyR is made up of a URI scheme, a domain, and a randomized component. This combination of data elements, in the form of a URI, is referred to specifically as a "location URI".
LBYRメカニズムの概念は簡単です。LBYRは、URIスキーム、ドメイン、およびランダム化されたコンポーネントで構成されています。URIの形式でのデータ要素のこの組み合わせは、特に「ロケーションURI」と呼ばれます。
A location URI is thought of as a reference to the current location of the Target, yet the location value might remain unchanged over specific intervals of time for several reasons. The type of location information returned as part of the dereferencing step may, for example, be influenced by the following factors:
URIは、ターゲットの現在の位置への参照と考えられていますが、いくつかの理由で特定の時間の間に位置値が変わらない場合があります。たとえば、繰り返しのステップの一部として返される位置情報の種類は、次の要因の影響を受ける可能性があります。
- Limitations in the process used to generate location information mean that cached location might be used.
- 位置情報を生成するために使用されるプロセスの制限により、キャッシュされた場所が使用される可能性があります。
- Policy constraints may dictate that the location provided remains fixed over time for specified Location Recipients. Without additional information, a Location Recipient cannot assume that the location information provided by any location URI is static, and will never change.
- ポリシーの制約により、提供された場所が指定された場所の受信者の時間の経過とともに固定されたままであることが規定される場合があります。追加情報がなければ、場所の受信者は、URIが任意の場所で提供される場所情報が静的であり、決して変更されないと想定することはできません。
The LbyR mechanism works according to an information life cycle. Within this life cycle, location URIs are considered temporary identifiers, each undergoing the following uses: Creation; Distribution; Conveyance; Dereference; and Termination. The use of a location URI according to these various states is generally applied in one of the following ways:
LBYRメカニズムは、情報ライフサイクルに従って機能します。このライフサイクル内では、ロケーションURIは一時的な識別子と見なされ、それぞれが次の使用を受けています。分布;運搬;拒否;および終了。これらのさまざまな状態に応じたロケーションURIの使用は、一般的に次のいずれかの方法で適用されます。
1. Creation of a location URI, within a location server, based on some request for its creation.
1. 作成のリクエストに基づいて、ロケーションサーバー内のロケーションURIの作成。
2. Distribution of a location URI, via a Location Configuration Protocol, between a Target and a location server.
2. ターゲットサーバーとロケーションサーバーの間のロケーション構成プロトコルを介して、ロケーションURIの配布。
3. Conveyance, applied to LbyR, for example in SIP (Session Initiation Protocol), is the transporting of the location URI, in this case, between any successive signaling nodes.
3. たとえば、SIP（セッション開始プロトコル）でLBYRに適用される運搬は、この場合、連続したシグナル伝達ノード間の位置URIの輸送です。
4. Dereference of a location URI, a request/response between a client having a location URI and a location server holding the location information that the location URI references.
4. ロケーションURIの控除、ロケーションURIを持つクライアントとロケーションサーバー間のリクエスト/応答、および場所URIが参照する位置情報を保持しています。
5. Termination of a location URI, due to either expiration or cancellation within a location server, and that is based on a Target cancellation request or some other action, such as timer expiration.
5. ロケーションサーバー内の有効期限またはキャンセルのいずれかにより、ロケーションURIの終了。これは、ターゲットキャンセル要求またはタイマーの有効期限などのその他のアクションに基づいています。
Note that this document makes no functional differentiation between a Location Server (LS), per [RFC3693], and a Location Information Server (LIS), as shown in [RFC5687], but may refer to either of them as a location server interchangeably.
このドキュメントは、[RFC5687]に示すように、[RFC3693]、および位置情報サーバー（LIS）ごとにロケーションサーバー（LS）と位置情報サーバー（LIS）を機能させないことに注意してください。
Location determination, as distinct from location configuration or dereferencing, often includes topics related to manual provisioning processes, automated location calculations based on a variety of measurement techniques, and/or location transformations (e.g., geo-coding), and is beyond the scope of this document.
位置決定は、位置構成または控除とは異なるように、多くの場合、手動のプロビジョニングプロセスに関連するトピック、さまざまな測定技術に基づく自動位置計算、および/または位置変換（例：ジオコーディング）、およびこのドキュメント。
Location Conveyance for either LbyR or LbyV, as defined within SIP signaling is considered out of scope for this document. (See [LOC-CONVEY] for an explanation of location conveyance for either LbyR or LbyV scenarios.)
SIPシグナル伝達内で定義されているように、LBYRまたはLBYVのいずれかの位置搬送は、このドキュメントの範囲外であると見なされます。（LBYRまたはLBYVシナリオのいずれかの位置搬送の説明については、[Loc Convey]を参照してください。）
Except for location conveyance, the above stages in the LbyR life cycle fall into one of two general categories of protocols, either a Location Configuration Protocol or a Location Dereference Protocol. The stages of LbyR Creation, Distribution, and Termination, are each found within the set of Location Configuration Protocols (LCPs). The Dereference stage belongs solely to the set of Location Dereference Protocols.
ロケーションの運搬を除き、LBYRライフサイクルの上記の段階は、ロケーション構成プロトコルまたは位置的な控除プロトコルの2つの一般的なカテゴリのプロトコルのいずれかに分類されます。LBYRの作成、分布、および終了の段階は、それぞれロケーション構成プロトコルのセット（LCPS）内で見つかります。抑制段階は、ロケーション控訴プロトコルのセットのみに属します。
The issues around location configuration protocols have been documented in a location configuration protocol problem statement and requirements document [RFC5687]. There are currently several examples of documented location configuration protocols, namely DHCP [DHCP-LOC-URI], LLDP-MED [LLDP-MED], and HELD [HELD].
ロケーション構成プロトコルに関する問題は、ロケーション構成プロトコル問題ステートメントと要件文書[RFC5687]に文書化されています。現在、文書化されたロケーション構成プロトコル、すなわちDHCP [DHCP-LOC-URI]、LLDP-Med [LLDP-Med]、および[保持]のいくつかの例がいくつかあります。
For dereferencing a location URI, depending on the type of reference used, such as a HTTP/HTTPS or SIP Presence URI, different operations can be performed. While an HTTP/HTTPS URI can be resolved to location information, a SIP Presence URI provides further benefits from the SUBSCRIBE/NOTIFY concept that can additionally be combined with location filters [LOC-FILTERS].
HTTP/HTTPSやSIP存在URIなど、使用する参照のタイプに応じて、ロケーションURIを参照するために、異なる操作を実行できます。HTTP/HTTPS URIは位置情報に解決できますが、SIPプレゼンスURIは、さらにロケーションフィルター[loc-filters]と組み合わせることができるサブスクライブ/通知コンセプトからさらに利益をもたらします。
The structure of this document includes terminology, Section 2, followed by a discussion of the basic elements that surround how a location URI is used. These elements, or actors, are discussed in an overview section, Section 3, accompanied by a graph, associated processing steps, and a brief discussion around the use, expiration, authorization, and construction of location URIs.
このドキュメントの構造には、用語であるセクション2が含まれ、その後、URIの使用方法を取り巻く基本要素の説明が含まれます。これらの要素、またはアクターについては、グラフ、関連する処理手順、およびロケーションの使用、有効化、許可、およびURISの構築に関する簡単な議論を伴う概要セクション3で説明されています。
Requirements are outlined accordingly, separated as location configuration requirements, Section 4.1, and location dereference requirements, Section 4.2.
それに応じて要件が概説されており、位置構成要件、セクション4.1、および位置控訴要件、セクション4.2として区切られています。
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], with the important qualification that, unless otherwise stated, these terms apply to the design of the Location Configuration Protocol and the Location Dereferencing Protocol, not its implementation or application.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [RFC2119]に記載されているように解釈されるために、特に明記しない限り、これらの用語は、その実装やアプリケーションではなく、位置構成プロトコルとロケーションの参照プロトコルの設計に適用されるという重要な資格があります。
This document reuses the terminology of [RFC3693], such as Location Server (LS), Location Recipient (LR), Rule Maker (RM), Target, and Location Object (LO). Furthermore, the following terms are defined in this document:
このドキュメントでは、ロケーションサーバー（LS）、ロケーション受信者（LR）、ルールメーカー（RM）、ターゲット、ロケーションオブジェクト（LO）など、[RFC3693]の用語を再利用します。さらに、次の用語はこのドキュメントで定義されています。
Location-by-Value (LbyV): Using location information in the form of a location object (LO), such as a PIDF-LO.
location by-value（LBYV）：PIDF-LOなどの位置オブジェクト（LO）の形式で位置情報を使用します。
Location-by-Reference (LbyR): Representing location information indirectly using a location URI.
Location by-Reference（LBYR）：ロケーションURIを使用して位置情報を間接的に表現します。
Location Configuration Protocol: A protocol that is used by a Target to acquire either a location object or a location URI from a location configuration server, based on information unique to the Target.
位置構成プロトコル：ターゲットに固有の情報に基づいて、ターゲットがロケーションオブジェクトまたはロケーション構成サーバーからロケーションURIを取得するために使用されるプロトコル。
Location Dereference Protocol: A protocol that is used by a client to query a location server, based on the location URI input, and that returns location information.
Location Dereference Protocol：ロケーションURI入力に基づいてロケーションサーバーを照会するためにクライアントが使用するプロトコル、および位置情報を返します。
Location URI: As defined within this document, an identifier that serves as a reference to location information. A location URI is provided by a location server, and is later used as input by a dereference protocol to retrieve location information.
場所URI：このドキュメント内で定義されているように、位置情報への参照として機能する識別子。ロケーションURIはロケーションサーバーによって提供され、後で位置情報を取得するための控訴プロトコルによって入力として使用されます。
This section describes the entities and interactions involved in the LbyR model.
このセクションでは、LBYRモデルに関連するエンティティとインタラクションについて説明します。
+---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS/LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (3) +-----+-----+
| * |
| Policy * |
Location | Exchange * |
Configuration | (*) * | Location
Protocol | +----+----+ | Conveyance
(1) | | Rule | | Protocol
| | Maker | | (2)
+----+----+ +---------+ |
| | |
| Target +-------------------------------+
| |
+---------+
Figure 1: Location Reference Entities and Interactions
図1：位置参照エンティティとインタラクション
Figure 1 shows the assumed communication model for both a Layer 7 location configuration protocol and a location dereference protocol.
図1は、レイヤー7ロケーション構成プロトコルと位置的控訴プロトコルの両方の想定通信モデルを示しています。
(1) The Target (an end device) uses a location configuration protocol to acquire a location reference from a LIS, which acts as (or is able to access) an LS.
(1) ターゲット（エンドデバイス）は、ロケーション構成プロトコルを使用して、LISから機能する（またはアクセスできる）LISからの位置参照を取得します。
In the case where the Target is also a Rule Maker, the location configuration protocol can be used to convey policy information.
ターゲットがルールメーカーでもある場合、ロケーション構成プロトコルを使用してポリシー情報を伝えることができます。
In the case where possession of a location URI is the only required form of authorization (see Section 3.3), a policy is implied whereby any requester is granted access to location information. This does not preclude other means of providing authorization policies.
URIの所有権が必要な唯一の承認形式である場合（セクション3.3を参照）、リクエスターが位置情報へのアクセスを許可されるポリシーが暗示されています。これは、認可ポリシーを提供する他の手段を排除するものではありません。
A Target could also acquire a location URI from the LS directly using alternative means, for example, the acquisition of a presence Address of Record (AoR) to be used for location information, in which case, it could be regarded as a location URI.
また、ターゲットは、別の手段を使用してLSからロケーションURIを取得することもできます。たとえば、位置情報に使用されるレコードの存在アドレス（AOR）の取得（その場合、それはロケーションURIと見なされる可能性があります。
(2) The Target conveys the location URI to the Location Recipient (interface out of scope).
(2) ターゲットは、場所URIを場所の受信者に伝えます（範囲外のインターフェイス）。
(3) The Location Recipient dereferences the location URI to acquire location information from the LS.
(3) 場所の受信者は、LSから位置情報を取得するための場所URIのというなむします。
The LS controls access to location information based on the policy provided by the Rule Maker.
LSは、ルールメーカーが提供するポリシーに基づいて、位置情報へのアクセスを制御します。
Note A. There is no requirement for using the same protocol in (1) and (3).
注A.（1）および（3）で同じプロトコルを使用するための要件はありません。
Note B. Figure 1 includes the interaction between the owner of the Target and the LIS to obtain Rule Maker policies. This interaction needs to happen before the LIS will authorize anything other than what is allowed based on default policies in order to dereference a location request of the Target. This communication path is out of scope for this document.
注B.図1には、ターゲットの所有者とLISの間の相互作用が含まれており、ルールメーカーポリシーを取得します。この相互作用は、LISがターゲットのロケーション要求を再参照するために、デフォルトのポリシーに基づいて許可されるもの以外のものを許可する前に行う必要があります。この通信パスは、このドキュメントの範囲外です。
Note C. The Target might take on the role of the Location Recipient, in which case, it could attempt to dereference the location URI itself, in order to obtain its own location information.
注C.ターゲットは、場所の受信者の役割を引き受ける可能性があります。その場合、独自の位置情報を取得するために、URI自体の位置自体を控除しようとする可能性があります。
An example scenario of how the above location configuration and location dereference steps might work using SIP is where a Target obtains a location URI in the form of a subscription URI (e.g., a SIP URI) via a location configuration protocol. In this case, the Target is the same as the Recipient; therefore, the Target can subscribe to the URI in order to be notified of its current location based on subscription parameters. In the example, parameters are set up for a specific Target/Recipient along with an expressed geospatial boundary, so that the Target/Recipient receives an updated location notification once the boundary is crossed (see [LOC-FILTERS]).
上記の位置構成と位置の抑制手順がSIPを使用して機能する方法の例のシナリオは、ターゲットがロケーション構成プロトコルを介してサブスクリプションURI（例えば、SIP URI）の形でロケーションURIを取得する場所です。この場合、ターゲットは受信者と同じです。したがって、ターゲットは、サブスクリプションパラメーターに基づいて現在の場所を通知するためにURIを購読できます。この例では、特定のターゲット/レシピエントと表現された地理空間境界に対してパラメーターが設定されているため、境界が交差するとターゲット/受信者が更新された場所通知を受け取ります（[loc-filters]を参照）。
Location URIs may have an expiry associated with them, primarily for security considerations, and generally in order for the LIS to keep track of the location URIs that have been handed out, to know whether a location URI is still valid once the LIS receives it in a request, and for preventing a recipient of such a URI from being able to (in some cases) permanently track a host. Expiration of a location URI limits the time that accidental leaking of a location URI introduces. Other justifications for expiration of location URIs include the ability for a LIS to do garbage collection.
位置URIは、主にセキュリティ上の考慮事項のために、そして一般的に、LISが配られた場所を追跡するために、それらに関連する有効期限を持っている可能性があります。リクエスト、およびそのようなURIの受信者が（場合によっては）恒久的にホストを永久に追跡できないようにするための要求。URIの有効期限は、URIが導入する場所の偶発的な漏れを制限します。URISの有効期限のためのその他の正当化には、LISがゴミ収集を行う能力が含まれます。
How a location URI will ultimately be used within the dereference step is an important consideration at the time the location URI is requested via a location configuration protocol. The process of dereferencing location URIs will be influenced by the specific authorization model applied by the Location Information Server and the URI scheme that indicates the protocol to be used to resolve the reference to a location object.
抑制ステップ内で最終的にURIが最終的に使用される方法は、URIがロケーション構成プロトコルを介して要求された時点で重要な考慮事項です。登録場所のプロセスURIは、位置情報サーバーと、ロケーションオブジェクトへの参照を解決するために使用されるプロトコルを示すURIスキームによって適用される特定の承認モデルの影響を受けます。
Location URIs manifest themselves in a few different forms. The different ways that a location URI can be represented are based on local policy, and are depicted in the following four scenarios.
場所は、いくつかの異なる形式で現れます。URIを表現できるさまざまな方法は、ローカルポリシーに基づいており、次の4つのシナリオに描かれています。
1. No location information included in the URI: As is typical, a location URI is used to get location information. However, in this case, the URI representation itself does not need to reveal any specific information at all. Location information is acquired by the dereferencing operation using a location URI.
1. URIには位置情報が含まれていません：典型的なように、URIは位置情報を取得するために使用されます。ただし、この場合、URI表現自体は特定の情報をまったく明らかにする必要はありません。位置情報は、ロケーションURIを使用して、繰り返しの操作によって取得されます。
2. URI does not identify a Target: By default, a location URI MUST NOT reveal any information about the Target other than location information. This is true for the URI itself (or in the document acquired by dereferencing), unless policy explicitly permits otherwise.
2. URIはターゲットを識別しません。デフォルトでは、URIの場所は、位置情報以外のターゲットに関する情報を明らかにしてはなりません。これは、ポリシーが明示的に特に許可されていない限り、URI自体（または控除によって取得された文書）に当てはまります。
3. Access control authorization model: If this model is used, the location URI MUST NOT include any location information in its representation. Location URIs operating under this model could be widely published to recipients that are not authorized to receive this information.
3. アクセス制御承認モデル：このモデルが使用されている場合、ロケーションURIには、その表現に位置情報を含めてはなりません。このモデルの下で動作するURISは、この情報を受け取ることを許可されていない受信者に広く公開できます。
4. Possession authorization model (the URI itself is a secret): If this model is used, the location URI is confidential information shared between the LIS/LS, the Target, and all authorized Location Recipients. In this case, possession implies authorization. Because knowledge of the location URI is used to authenticate and authorize access to location information, the URI needs to include sufficient randomness to make guessing its value difficult. A possession model URI can include location information in its representation.
4. 所有権認証モデル（URI自体は秘密です）：このモデルが使用される場合、URIの場所は、LIS/LS、ターゲット、およびすべての認定場所の受信者の間で共有される機密情報です。この場合、所有は許可を意味します。URIの知識は、位置情報へのアクセスを認証および承認するために使用されるため、URIはその価値を推測するために十分なランダム性を含める必要があります。所有モデルURIは、その表現に位置情報を含めることができます。
Given scenarios 2 and 4, above, and depending on local policy, a location URI may be constructed in such a way as to make it difficult to guess. Accordingly, the form of the URI is then constrained by the degree of randomness and uniqueness applied to it. In this case, it may be important to protect the actual location information from inspection by an intermediate node. Construction of a location URI in such a way as to not reveal any Target-specific information (e.g., user or device information), with the goal of making the location URI appear bland, uninteresting, and generic, may be helpful to some degree in order to keep location information more difficult to detect. Thus, obfuscating the location URI in this way may provide some level of safeguard against the undetected inspection and unintended use of what would otherwise be evident location information, since it forces a dereference operation at the location dereference server, an important step for the purpose of providing statistics, audit trails, and general logging for many different kinds of location-based services.
上記のシナリオ2および4を考慮して、ローカルポリシーに応じて、推測を困難にするような方法でURIが構築される場合があります。したがって、URIの形式は、それに適用されるランダム性と一意性の程度によって制約されます。この場合、中間ノードによる検査から実際の位置情報を保護することが重要かもしれません。ターゲット固有の情報（ユーザーやデバイス情報など）を明らかにしないような場所での場所を構築します。位置情報を検出がより困難に保つために。したがって、この方法でURIの位置を難読化すると、検出されていない検査と、そうでなければ明白な位置情報の意図しない使用に対するある程度の保護手段を提供する可能性があります。さまざまな種類の位置ベースのサービスに統計、監査証跡、および一般ロギングを提供します。
This document outlines the requirements for a Location by Reference mechanism that can be used by a number of underlying protocols. Requirements here address two general types of such protocols, a general location configuration protocol and a general location dereferencing protocol.
このドキュメントでは、多くの基礎となるプロトコルで使用できる参照メカニズムによる場所の要件の概要を説明しています。ここでの要件は、このようなプロトコルの2つの一般的なタイプ、一般的な場所構成プロトコル、および一般的な位置緩和プロトコルに対処します。
The requirements are broken into two sections.
要件は2つのセクションに分かれています。
Below, we summarize high-level design requirements needed for a location-by-reference mechanism as used within the location configuration protocol.
以下では、ロケーション構成プロトコル内で使用される場所ごとのメカニズムに必要な高レベルの設計要件を要約します。
C1. Location URI support: The location configuration protocol MUST support a location reference in URI form.
C1。ロケーションURIサポート：ロケーション構成プロトコルは、URI形式のロケーションリファレンスをサポートする必要があります。
Motivation: A standardized location reference mechanism increases interoperability.
動機：標準化された位置参照メカニズムにより、相互運用性が向上します。
C2. Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated.
C2。ロケーションURIの有効期限：ロケーションURIの有効性間隔が限られている場合、その寿命を示す必要があります。
Motivation: A location URI may not intend to represent a location forever, and the identifier eventually may need to be recycled, or may be subject to a specific window of validity, after which the location reference fails to yield a location, or the location is determined to be kept confidential.
動機：URIが永遠に場所を表すつもりはない可能性があり、識別子を最終的にリサイクルする必要があるか、特定の有効性の窓の対象となる場合があります。機密に保たれると判断されました。
C3. Location URI cancellation: The location configuration protocol MUST support the ability to request a cancellation of a specific location URI.
C3。場所URIキャンセル：場所構成プロトコルは、特定の場所URIのキャンセルを要求する機能をサポートする必要があります。
Motivation: If the Target determines that a location URI should no longer be used to dereference a location, then there should be a way to request that the location URI be nullified.
動機：ターゲットが場所を抑制するために使用されなくなったと判断した場合、場所を無効にすることを要求する方法があるはずです。
C4. Location information masking: The location URI MUST ensure, by default, through randomization and uniqueness, that the location URI does not contain location-information-specific components.
C4。位置情報のマスキング：URIは、デフォルトでは、ランダム化と一意性を通じて、ロケーションURIに位置情報固有のコンポーネントが含まれていないことを保証する必要があります。
Motivation: It is important to keep any location information masked from a casual observing node.
動機：カジュアルな観測ノードから任意の位置情報を隠しておくことが重要です。
C5. Target identity protection: The location URI MUST NOT contain information that identifies the Target (e.g., user or device). Examples include phone extensions, badge numbers, and first or last names.
C5。ターゲットのID保護：ターゲット（ユーザーまたはデバイスなど）を識別する情報をuriに含めるべきではありません。例には、電話拡張機能、バッジ番号、姓または姓が含まれます。
Motivation: It is important to protect caller identity or contact address from being included in the form of the location URI itself when it is generated.
動機：発信者の身元または連絡先住所を、生成時にURI自体の形式に含まれることを防ぐことが重要です。
C6. Reuse indicator: There SHOULD be a way to allow a Target to control whether a location URI can be resolved once only or multiple times.
C6。再利用インジケーター：ターゲットが場所を1回だけまたは複数回解決できるかどうかをターゲットに制御できるようにする方法があるはずです。
Motivation: The Target requesting a location URI may request a location URI that has a 'one-time-use' only characteristic, as opposed to a location URI having multiple reuse capability. This would allow the server to return an error with or without location information during the subsequent dereference operation.
動機：URIを要求するターゲットは、複数の再利用機能を備えた場所とは対照的に、「1回限りの使用」の唯一の特性を持つロケーションのURIを要求できます。これにより、サーバーは、後続の抑制操作中に位置情報の有無にかかわらずエラーを返すことができます。
C7. Selective disclosure: The location configuration protocol MUST provide a mechanism that allows the Rule Maker to control what information is being disclosed about the Target.
C7。選択的開示：位置構成プロトコルは、ルールメーカーがターゲットについて開示されている情報を制御できるメカニズムを提供する必要があります。
Motivation: The Rule Maker has to be in control of how much information is revealed during the dereferencing step as part of the privacy features.
モチベーション：ルールメーカーは、プライバシー機能の一部として、繰り返しのステップ中にどのくらいの情報が明らかにされるかを制御する必要があります。
C8. Location URI not guessable: As a default, the location configuration protocol MUST return location URIs that are random and unique throughout the indicated lifetime. A location URI with 128 bits of randomness is RECOMMENDED.
C8。場所URIは推測できません：デフォルトとして、位置構成プロトコルは、指定された寿命を通してランダムで一意の位置URIを返す必要があります。128ビットのランダム性を持つロケーションURIが推奨されます。
Motivation: Location URIs should be constructed in such a way that an adversary cannot guess them and dereference them without having previously obtained them from the Target.
動機：ロケーションウリは、敵がそれらを推測し、以前にターゲットから入手しなくても控えめにできないように構築する必要があります。
C9. Location URI options: In the case of user-provided authorization policies, where anonymous or non-guessable location URIs are not warranted, the location configuration protocol MAY support a variety of optional location URI conventions, as requested by a Target to a location configuration server (e.g., embedded location information within the location URI).
C9。ロケーションURIオプション：匿名または誘惑不可能な場所が保証されていないユーザーが提供する認可ポリシーの場合、ロケーション構成プロトコルは、ターゲットがロケーション構成サーバーにリクエストするように、さまざまなオプションの場所URIコンベンションをサポートする場合があります。（たとえば、埋め込まれた場所URI内に埋め込まれた位置情報）。
Motivation: Users don't always have such strict privacy requirements, but may opt to specify their own location URI or components to be included within a location URI.
動機：ユーザーは常にそのような厳格なプライバシー要件を持っているわけではありませんが、ロケーションURIに含まれる独自の場所のURIまたはコンポーネントを指定することを選択できます。
Below, we summarize high-level design requirements needed for a location-by-reference mechanism as used within the location dereference protocol.
以下では、ロケーション控訴プロトコル内で使用される場所ごとのメカニズムに必要な高レベルの設計要件を要約します。
D1. Location URI support: The location dereference protocol MUST support a location reference in URI form.
D1。ロケーションURIサポート：位置的な控訴プロトコルは、URI形式の位置参照をサポートする必要があります。
Motivation: It is required that there be consistency of use between location URI formats used in a configuration protocol and those used by a dereference protocol.
動機：構成プロトコルで使用される位置URI形式と控除プロトコルで使用されているものとの間で使用の一貫性があることが必要です。
D2. Authentication: The location dereference protocol MUST include mechanisms to authenticate both the client and the server.
D2。認証：位置的な抑制プロトコルには、クライアントとサーバーの両方を認証するメカニズムを含める必要があります。
Motivation: Although the implementations must support authentication of both parties, any given transaction has the option not to authenticate one or both parties.
動機：実装は両当事者の認証をサポートする必要がありますが、特定の取引には、一方または両方の当事者を認証しないオプションがあります。
D3. Dereferenced location form: The value returned by the dereference protocol MUST contain a well-formed PIDF-LO document.
D3。参照された位置フォーム：控訴プロトコルによって返される値には、よく形成されたPIDF-LOドキュメントが含まれている必要があります。
Motivation: This is in order to ensure that adequate privacy rules can be adhered to, since the PIDF-LO format comprises the necessary structures to maintain location privacy.
動機：これは、PIDF-LO形式がロケーションプライバシーを維持するために必要な構造を構成するため、適切なプライバシールールを順守できるようにするためです。
D4. Location URI repeated use: The location dereference protocol MUST support the ability for the same location URI to be resolved more than once, based on dereference server configuration.
D4。ロケーションURIの繰り返し使用：位置的な控訴プロトコルは、控えめなサーバーの構成に基づいて、同じ場所URIを複数回解決する機能をサポートする必要があります。
Motivation: Through dereference server configuration, for example, it may be useful to not only allow more than one dereference request, but, in some cases, to also limit the number of dereferencing attempts by a client.
動機：たとえば、控除サーバーの構成を通じて、複数の繰り返しの要求を許可するだけでなく、場合によっては、クライアントによる控除の試みの数も制限することが役立つ場合があります。
D5. Location confidentiality: The location dereference protocol MUST support confidentiality protection of messages sent between the Location Recipient and the location server.
D5。位置の機密性：場所の抑制プロトコルは、ロケーション受信者とロケーションサーバーの間で送信されるメッセージの機密性保護をサポートする必要があります。
Motivation: The location URI indicates what type of security protocol has to be provided. An example is a location URI using a HTTPS URI scheme.
動機：場所URIは、どのタイプのセキュリティプロトコルを提供する必要があるかを示します。例は、HTTPS URIスキームを使用した場所URIです。
The method of constructing the location URI to include randomized components helps to prevent adversaries from obtaining location information without ever retrieving a location URI. In the possession model, a location URI, regardless of its construction, if made publicly available, implies no safeguard against anyone being able to dereference and get the location. Care has to be paid when distributing such a location URI to the trusted location recipients. When this aspect is of concern, the authorization model has to be chosen. Even in this model, care has to be taken on how to construct the authorization policies to ensure that only those parties have access to location information that are considered trustworthy enough to enforce the basic rule set that is attached to location information in a PIDF-LO document.
ランダム化されたコンポーネントを含めるようにロケーションURIを構築する方法は、敵がロケーションURIを取得せずに位置情報を取得するのを防ぐのに役立ちます。所有モデルでは、その建設に関係なく、URIの位置は、公開されている場合、誰もがその場所を取得して取得できることに対する保護を意味しません。このような場所を信頼できる場所の受信者に配布する場合は、注意する必要があります。この側面が懸念される場合、承認モデルを選択する必要があります。このモデルでさえ、PIDF-LOの位置情報に添付されている基本的なルールセットを実施するのに十分な信頼できると考えられる場所情報にアクセスできるように、許可ポリシーを構築する方法に注意する必要があります。書類。
Any location URI, by necessity, indicates the server (name) that hosts the location information. Knowledge of the server in some specific domain could therefore reveal something about the location of the Target. This kind of threat may be mitigated somewhat by introducing another layer of indirection: namely the use of a (remote) presence server.
必要に応じて、任意のロケーションURIは、位置情報をホストするサーバー（名前）を示します。したがって、いくつかの特定のドメイン内のサーバーの知識は、ターゲットの位置に関する何かを明らかにする可能性があります。この種の脅威は、間接の別のレイヤー、つまり（リモート）存在サーバーの使用を導入することにより、多少軽減される可能性があります。
A covert channel for protocol message exchange is an important consideration, given an example scenario where user A subscribes to location information for user B, then every time A gets a location update, an (external) observer of the subscription notification may know that B has moved. One mitigation of this is to have periodic notification, so that user B may appear to have moved even when static.
プロトコルメッセージ交換用のカバーチャネルは、ユーザーAがユーザーBの位置情報を購読するシナリオの例を考えると、重要な考慮事項です。動いた。これの1つの緩和は、定期的な通知を持つことで、ユーザーBが静的にも移動したように見えることがあります。
I would like to thank the present IETF GEOPRIV working group chairs, Alissa Cooper and Richard Barnes, past chairs, Robert Sparks, Andy Newton, Allison Mankin, and Randall Gellens, who established a design team that initiated this requirements work. I'd also like to thank those original design team participants for their inputs, comments, and insightful reviews. The design team included the following folks: Richard Barnes, Martin Dawson, Keith Drage, Randall Gellens, Ted Hardie, Cullen Jennings, Marc Linsner, Rohan Mahy, Allison Mankin, Andrew Newton, Jon Peterson, James M. Polk, Brian Rosen, John Schnizlein, Henning Schulzrinne, Barbara Stark, Hannes Tschofenig, Martin Thomson, and James Winterbottom.
現在のIETF Geoprivワーキンググループの椅子、アリッサクーパーとリチャードバーンズ、過去の椅子、ロバートスパークス、アンディニュートン、アリソンマンキン、ランドールゲレンズに感謝します。また、元のデザインチームの参加者の入力、コメント、洞察に満ちたレビューについても感謝したいと思います。デザインチームには、リチャード・バーンズ、マーティン・ドーソン、キース・ドレイジ、ランドール・ゲレンズ、テッド・ハーディ、カレン・ジェニングス、マーク・リンナー、ローハン・マヒー、アリソン・マンキン、アンドリュー・ニュートン、ジョン・ピーターソン、ジェームズ・M・ポルク、ブリアン・ローゼン、ジョンの次の人々が含まれていました。Schnizlein、Henning Schulzrinne、Barbara Stark、Hannes Tschofenig、Martin Thomson、James Winterbottom。
[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月。
[DHCP-LOC-URI] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", Work in Progress, March 2010.
[DHCP-LOC-URI] POLK、J。、「ダイナミックホスト構成プロトコル（DHCP）IPv4およびIPv6オプションの位置ユニフォームリソース識別子（URI）オプション」、2010年3月の作業。
[HELD] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", Work in Progress, August 2009.
[Hold] Barnes、M.、Winterbottom、J.、Thomson、M。、およびB. Stark、「HTTP対応の位置配信（保有）」、2009年8月の作業。
[LLDP-MED] Telecommunications Industry Association (TIA), "ANSI/TIA-1057 Link Layer Discovery Protocol - Media Endpoint Discovery", 2006.
[LLDP-MED] Telecommunications Industry Association（TIA）、「ANSI/TIA-1057リンクレイヤーディスカバリープロトコル - メディアエンドポイントディスカバリー」、2006年。
[LOC-FILTERS] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in the Session Initiation Protocol (SIP)", Work in Progress, March 2010.
[loc-filters] Mahy、R.、Rosen、B。、およびH. Tschofenig、「セッション開始プロトコル（SIP）の位置通知のフィルタリング」、2010年3月の作業。
[LOC-CONVEY] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", Work in Progress, February 2010.
[Loc Convey] Polk、J。and B. Rosen、「セッション開始プロトコルの位置輸送」、2010年2月に進行中の作業。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687] Tschofenig、H。およびH. Schulzrinne、「Geopriv Layer 7位置構成プロトコル：問題ステートメントと要件」、RFC 5687、2010年3月。
Author's Address
著者の連絡先
Roger Marshall (editor) TeleCommunication Systems, Inc. 2401 Elliott Avenue 2nd Floor Seattle, WA 98121 US
Roger Marshall（編集者）Telecommunication Systems、Inc。2401 Elliott Avenue 2階シアトル、ワシントン州98121 US
Phone: +1 206 792 2424
EMail: rmarshall@telecomsys.com
URI: http://www.telecomsys.com