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（Uniform Resource Identifier）を使用してロケーション・バイ・リファレンス・アプローチに関連する要件を提供します。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
その作成のためのいくつかの要求に基づいて、位置サーバ内の場所URI、1.作成。
2. Distribution of a location URI, via a Location Configuration Protocol, between a Target and a location server.
ターゲットと位置サーバ間の位置構成プロトコルを介してロケーションURIの2分布、。
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.
LbyRに適用3.搬送は、SIP（セッション開始プロトコル）で、例えば、任意の連続したシグナリングノード間で、この場合には、ロケーション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.
ロケーションURIの4逆参照は、クライアント間の要求/応答は、ロケーション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.
前記位置サーバ内のいずれかの満了又はキャンセルによる位置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.
このドキュメントは[RFC3693]あたり、ロケーションサーバ（LS）との間には機能的な分化をしないように注意し、そして位置情報サーバ（LIS）、[RFC5687]に示すように、しかし互換的ロケーションサーバとしてのそれらのいずれかを指すことができます。
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.)
LbyR又はLbyVのいずれかの場所搬送は、SIPシグナリング内で定義されたように、この文書の範囲外であると考えられます。 （LbyR又はLbyVシナリオのいずれかの位置搬送の説明については[LOC-伝える]参照）。
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作成、配布、および終了の段階は、各ロケーションの設定プロトコル（のLCP）のセット内で見出されます。間接参照ステージは、単に場所逆参照プロトコルのセットに属します。
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]、保持された[HELD]現在存在します。
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]と組み合わせることができるSUBSCRIBE / NOTIFY概念からさらなる利点を提供します。
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.
この文書の構造が位置URIを使用する方法を取り囲む基本的な要素についての議論に続いて、用語、セクション2を含みます。これらの要素、またはアクターは、グラフ、関連する処理ステップ、およびロケーションURIの使用、有効期限、認可、および建設の周りに簡単な説明を伴う概要セクション、第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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
場所ごとの値（LbyV）：このようなPIDF-LOとして、位置オブジェクト（LO）の形で位置情報を使用。
Location-by-Reference (LbyR): Representing location information indirectly using a location URI.
ロケーション・バイ・リファレンス（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.
位置逆参照プロトコル：ロケーション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）ターゲット（エンド装置）として機能する（またはアクセスすることができる）LSを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.
ターゲットはまた、直接、例えば、レコード（AOR）の存在アドレスの取得は、その場合には、それが位置URIとみなすことができ、位置情報のために使用される、代替的な手段を用いてLSからロケーション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]).
ターゲットロケーション構成プロトコルを介して加入URI（例えば、SIP URI）の形で位置URIを取得する場合の手順を逆参照上の位置設定及び位置は、SIPを使用して動作する方法の例のシナリオです。この場合、ターゲットは、レシピエントと同じです。そのため、ターゲットは、サブスクリプション・パラメータに基づいて、現在の位置を通知するために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を追跡するためにLISためには、一般的に、主にセキュリティ上の考慮事項については、それに関連付けられた有効期限を有していてもよく、 、および（場合によっては）永久ホストを追跡することができることから、そのようなURIの受信者を防止するための要求。ロケーションURIの有効期限は、URIが導入位置の漏洩偶発的な時間を制限します。場所のURIの満了のためのその他の正当化は、ガベージコレクションを実行する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は、いくつかの異なる形で現れます。ロケーション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はその表現の任意の位置情報を含んではいけません。このモデルの下で作動する場所のURIは広く、この情報を受信することが許可されていない受信者に公開することができます。
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の建設は、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.
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。アイデンティティ保護を標的：ロケーション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.
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。指標の再利用：ターゲットは場所URIが一度のみ、または複数回解決できるかどうかを制御することができるようにする方法があるはずです。
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.
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規則の様々なサポートするかもしれ（例えば、ロケーション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.
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.
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.
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.
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は、関係なく、その構造の、公に利用可能ならば、誰もが逆参照することができることと場所を取得に対しては安全装置がないことを意味します。ケアは、信頼できる場所の受信者に、このような場所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の位置情報をサブスクライブの例のシナリオでは、Aは、位置更新、サブスクリプション通知の（外部の）観察者がBが有することを知ることができる取得するたびに与えられ、重要な考慮事項であります移動。この一の緩和は、ユーザ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ワーキンググループチェア、アリッサ・クーパーとリチャード・バーンズ、過去の椅子、ロバート・スパークス、アンディ・ニュートン、アリソンマンキン、この要件作業を開始した設計チームを設立ランドールGellensを、感謝したいと思います。私はまた、それらの入力、コメント、洞察力にレビューのためにそれらのオリジナルのデザインチームの参加者に感謝したいと思います。リチャード・バーンズ、マーティン・ドーソン、キース糖剤、ランドールGellens、テッドハーディー、カレン・ジェニングス、マルク・Linsner、ロハンマーイ、アリソンマンキン、アンドリュー・ニュートン、ジョンピーターソン、ジェームズ・M.ポーク、ブライアン・ローゼン、ジョン：設計チームは、次の人々が含まれてSchnizlein、ヘニングSchulzrinneと、バーバラ・スターク、ハンネスTschofenig、マーティン・トムソン、そしてジェームズ・ウィンターボトム。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ポーク、J.、 "動的ホスト構成プロトコル（DHCP）IPv4とIPv6オプション場所のURI（Uniform Resource Identifier）のために"、進歩、2010年3月での作業。
[HELD] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", Work in Progress, August 2009.
バーンズ、M.、ウィンターボトム、J.、トムソン、M.、およびB.スターク、 "HTTP（保持）有効場所の配信を"、進歩、2009年8月に作業が[HELD]。
[LLDP-MED] Telecommunications Industry Association (TIA), "ANSI/TIA-1057 Link Layer Discovery Protocol - Media Endpoint Discovery", 2006.
[LLDP-MED]電気通信工業会（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]マーイ、R.、ローゼン、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-伝え]ポーク、J.とB.ローゼン、「セッション開始プロトコルのための場所搬送」、進歩、2010年2月で仕事を。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、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レイヤ7場所構成プロトコル：問題文と要件"、RFC 5687、2010年3月。
Author's Address
著者のアドレス
Roger Marshall (editor) TeleCommunication Systems, Inc. 2401 Elliott Avenue 2nd Floor Seattle, WA 98121 US
ロジャー・マーシャル（エディタ）通信システム株式会社2401年エリオットアベニュー2階シアトル、WA 98121米国
Phone: +1 206 792 2424 EMail: rmarshall@telecomsys.com URI: http://www.telecomsys.com
電話：+1 206 792 2424 Eメール：rmarshall@telecomsys.com URI：http://www.telecomsys.com