[要約] RFC 6155は、HTTP-Enabled Location Delivery (HELD)でデバイスの識別子を使用する方法についての規格です。その目的は、位置情報の配信においてデバイスの識別と関連情報の提供を効率的に行うことです。
Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6155 M. Thomson
Category: Standards Track Andrew Corporation
ISSN: 2070-1721 H. Tschofenig
Nokia Siemens Networks
R. Barnes
BBN Technologies
March 2011
Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
http対応の位置配信でのデバイスアイデンティティの使用（保持）
Abstract
概要
When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.
位置情報サーバーが、ベースHTTP対応の位置配信（保有）仕様で説明されているロケーション情報のリクエスト（LocationRequestメッセージを使用）を受信すると、到着メッセージのソースIPアドレスをロケーション決定プロセスへのポインターとして使用します。これは、IPアドレスに基づいてデバイスの場所を決定できる環境で十分です。
Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.
このドキュメントでは、2つの追加のユースケースが対処されています。最初に、場所の構成には、リクエストで提供されるソースIPアドレスから追加または代替の識別子が必要です。2番目では、デバイス以外のエンティティがデバイスの場所を要求します。
This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted.
このドキュメントは、保持されているプロトコルを拡張して、ロケーションリクエストメッセージがデバイス識別子を運ぶことができるようにします。プライバシーとセキュリティの考慮事項識別子を含むリクエストが許可されている条件を説明しています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc6155.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6155で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7
2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
2.1.3. Network Interfaces and Devices . . . . . . . . . . . . 9
2.2. Identifier Format and Protocol Details . . . . . . . . . . 9
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
3.4.1. Using NAI for Location Configuration . . . . . . . . . 13
3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14
3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14
3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 15
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15
4.1. Targets Requesting Their Own Location . . . . . . . . . . 16
4.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18
5.2. Targets Requesting Their Own Location . . . . . . . . . . 18
5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19
6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 22
7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Protocols for requesting and providing location information require a way for the requestor to specify the location that should be returned. In a Location Configuration Protocol (LCP), the location being requested is the requestor's location. This fact can make the problem of identifying the Device simple, since IP datagrams that carry the request already carry an identifier for the Device -- namely, the source IP address of an incoming request. Existing LCPs, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] and DHCP ([RFC3825], [RFC4776]) rely on the source IP address or other information present in protocol datagrams to identify a Device.
位置情報を要求して提供するためのプロトコルには、リクエスターが返品する場所を指定する方法が必要です。ロケーション構成プロトコル（LCP）では、要求されている場所は要求者の場所です。この事実は、リクエストを伝えるIPデータグラムがデバイスの識別子、つまり着信リクエストのソースIPアドレスを既に運ぶためです。HTTP対応の位置配信（保有）[RFC5985]およびDHCP（[RFC3825]、[RFC4776]）などの既存のLCPは、プロトコルデータグラムに存在するソースIPアドレスまたはその他の情報に依存してデバイスを特定します。
Aside from the datagrams that form a request, a Location Information Server (LIS) does not necessarily have access to information that could further identify the Device. In some circumstances, as shown in [RFC5687], additional identification information can be included in a request to identify a Device.
リクエストを形成するデータグラムとは別に、Location Information Server（LIS）は、必ずしもデバイスをさらに識別できる情報にアクセスできるわけではありません。[RFC5687]に示されているように、状況によっては、追加の識別情報をデバイスを識別するリクエストに含めることができます。
This document extends the HELD protocol to support the inclusion of additional identifiers for the Device in HELD location requests. An XML schema is defined that provides a structure for including these identifiers in HELD requests.
このドキュメントは、保持されているプロトコルを拡張して、開催された場所リクエストにデバイスに追加の識別子を含めることをサポートします。XMLスキーマが定義されており、これらの識別子を保有リクエストに含めるための構造を提供します。
An important characteristic of this addition is that the HELD protocol with identity extensions implemented is not considered an LCP. The scope of an LCP is limited to the interaction between a Device and a LIS, and LCPs can guarantee the identity of Devices without additional authorization checks. A LIS identifies the Device making the LCP request using the source addressing on the request packets, using return routability to ensure that these identifiers are not spoofed.
この追加の重要な特徴は、実装されたアイデンティティ拡張機能を備えた保持されているプロトコルがLCPとは見なされないことです。LCPの範囲は、デバイスとLIS間の相互作用に限定されており、LCPは追加の承認チェックなしでデバイスのIDを保証できます。LISは、リクエストパケットにアドレス指定するソースを使用してLCPリクエストを作成するデバイスを識別します。これは、これらの識別子がスプーフィングされていないことを確認するために、返品ルーティング可能性を使用します。
HELD with identity extensions allows a requestor to explicitly provide identification details in the body of a location request. This means that location requests can be made in cases where additional Device identity checks are necessary, and in cases where the requestor is not the Device itself. Third-party Location Recipients (LRs) are able to make requests that include identifiers to retrieve location information about a particular Device.
ID拡張機能を備えた保持されると、リクエスターはロケーションリクエストの本文で明示的に識別の詳細を提供できます。これは、追加のデバイスIDチェックが必要な場合、および要求者がデバイス自体ではない場合に、場所のリクエストを作成できることを意味します。サードパーティのロケーション受信者（LRS）は、特定のデバイスに関する位置情報を取得するための識別子を含むリクエストを行うことができます。
The usage of identifiers in HELD introduces a new set of privacy concerns. In an LCP, the requestor can be implicitly authorized to access the requested location information, because it is their own location. In contrast, a third-party LR must be explicitly authorized when requesting the location of a Device. Establishing appropriate authorization and other related privacy concerns are discussed in Section 4.
Heldの識別子の使用は、新しいプライバシーの懸念事項を導入します。LCPでは、要求者は、独自の場所であるため、要求された位置情報にアクセスすることを暗黙的に許可することができます。対照的に、デバイスの場所を要求するときに、サードパーティのLRを明示的に許可する必要があります。適切な承認とその他の関連するプライバシーの懸念を確立することについて、セクション4で説明します。
This document defines a means to explicitly include Device identity information in the body of a HELD location request. This identity information is used to identify the Device that is the subject (or Target) of the location request. If Device identity is present, the identity of the requestor in the form of the source IP address is not used to identify the subject of the request.
このドキュメントでは、保有場所リクエストの本文にデバイスID情報を明示的に含める手段を定義しています。このID情報は、ロケーションリクエストの主題（またはターゲット）であるデバイスを識別するために使用されます。デバイスのアイデンティティが存在する場合、ソースIPアドレスの形式での要求者のIDは、リクエストの主題を識別するために使用されません。
Device identifiers in HELD can be used for two purposes:
保有のデバイス識別子は、2つの目的で使用できます。
Location configuration: A Device can use these parameters to identify itself to a LIS. Identification information other than an IP address might be needed to determine the location of a Device.
位置構成：デバイスはこれらのパラメーターを使用して、LISに識別できます。デバイスの場所を決定するには、IPアドレス以外の識別情報が必要になる場合があります。
A LIS can authorize location configuration requests using a policy that allows Devices to acquire their own location (see Section 4.1). If an unauthorized third party falsifies addressing on request packets to match the provided Device identity, the request might be erroneously authorized under this policy. Requests containing Device identity MUST NOT be authorized using this policy unless specific measures are taken to prevent this type of attack.
LISは、デバイスが独自の場所を取得できるようにするポリシーを使用して、位置構成要求を承認できます（セクション4.1を参照）。許可されていない第三者が、提供されたデバイスのIDと一致するように要求に応じてアドレス指定を偽造する場合、このポリシーの下でリクエストが誤って許可される可能性があります。このタイプの攻撃を防ぐために具体的な措置が取られない限り、デバイスのIDを含む要求は、このポリシーを使用して許可してはなりません。
This document describes a mechanism that provides assurances that the requestor and included Device identity are the same for the Network Access Identifier (NAI) in a WiMAX network. The LIS MUST treat requests containing other identifiers as third-party requests, unless it is able to ensure that the provided Device identity is uniquely attributable to the requestor.
このドキュメントでは、要求者と含まれているデバイスのIDがWimaxネットワークのネットワークアクセス識別子（NAI）で同じであるという保証を提供するメカニズムについて説明します。LISは、提供されたデバイスのアイデンティティが要求者に一意に起因することを確認できない限り、他の識別子を含む他の識別子を含む要求をサードパーティの要求として扱う必要があります。
Third-party requests: A third-party Location Recipient can be granted authorization to make requests for a given Device. In particular, network services can be permitted to retrieve location for a Device that is unable to acquire location information for itself (see Section 6.3 of [EMERGENCY-CALLING]). This allows use of location-dependent applications -- particularly essential services like emergency calling -- where Devices do not support a location configuration protocol or they are unable to successfully retrieve location information.
サードパーティのリクエスト：サードパーティの場所の受信者は、特定のデバイスのリクエストを行う許可を付与できます。特に、ネットワークサービスは、それ自体の位置情報を取得できないデバイスの場所を取得することができます（[緊急呼び出し]のセクション6.3を参照）。これにより、場所に依存するアプリケーション（特に緊急通話などの重要なサービス）を使用することができます。デバイスがロケーション構成プロトコルをサポートしていない場合、または位置情報を正常に取得できません。
This document does not describe how a third party acquires an identifier for a Device, nor how that third party is authorized by a LIS. It is critical that these issues are resolved before permitting a third-party request. A pre-arranged contract between the third party, a Rule Maker, and the LIS operator is necessary to use Device identifiers in this fashion. This contract must include how the request is authenticated and the set of identifiers (and types of identifiers) that the third party is authorized to use in requests.
このドキュメントでは、サードパーティがデバイスの識別子をどのように取得するか、またその第三者がLISによってどのように承認されるかについては説明していません。サードパーティの要求を許可する前に、これらの問題を解決することが重要です。この方法でデバイス識別子を使用するには、サードパーティ、ルールメーカー、およびLISオペレーターの間の事前に配置された契約が必要です。この契約には、リクエストの認証方法と、第三者がリクエストで使用することが許可されている識別子のセット（および識別子の種類）を含める必要があります。
Automated mechanisms to ensure that privacy constraints are respected are possible. For instance, a policy rules document could be used to express the agreed policy. Formal policy documents, such as the common policy [RFC4745], can be applied in an automated fashion by a LIS.
プライバシーの制約が尊重されることを保証するための自動化されたメカニズムが可能です。たとえば、ポリシールール文書を使用して、合意されたポリシーを表現できます。一般的なポリシー[RFC4745]などの正式なポリシー文書は、LISによって自動化された方法で適用できます。
This document uses the term Location Information Server (LIS) and Location Configuration Protocol (LCP) as described in [RFC5687] and [GEOPRIV-ARCH].
このドキュメントでは、[RFC5687]および[Geopriv-Arch]で説明されているように、Location Information Server（LIS）と位置構成プロトコル（LCP）という用語を使用しています。
The term Device is used specifically as the subject of an LCP, consistent with [RFC5985]. This document also uses the term Target to refer to any entity that might be a subject of the same location information. Target is used in a more general sense, including the Device, but also any nearby entity, such as the user of a Device.
この用語は、[RFC5985]と一致して、LCPの対象として特異的に使用されます。このドキュメントでは、ターゲットという用語を使用して、同じ位置情報の主題である可能性のあるエンティティを参照します。ターゲットは、デバイスを含むより一般的な意味で使用されますが、デバイスのユーザーなどの近くのエンティティも使用されます。
A Target has a stake in setting authorization policy on the use of location information. A Rule Maker is the term used for the role that makes policy decisions about authorization, determining what entities are permitted to receive location and how that information is provided.
ターゲットは、位置情報の使用に関する承認ポリシーを設定することに関与しています。ルールメーカーは、認可に関するポリシー決定を行う役割に使用される用語であり、場所を受け取ることが許可されているエンティティとその情報の提供方法を決定するものです。
Device, Target, and Rule Maker are defined in [GEOPRIV-ARCH].
デバイス、ターゲット、およびルールメーカーは[Geopriv-arch]で定義されています。
The term "requestor" is used in this document to refer to the entity making a HELD request.
このドキュメントでは、「要求者」という用語が使用されており、保有リクエストを行うエンティティを指すために使用されます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Identifiers are used as the starting point in location determination. Identifiers might be associated with a different Device over time, but their purpose is to identify the Device, not to describe its environment or network attachment.
識別子は、場所の決定の開始点として使用されます。識別子は時間の経過とともに異なるデバイスに関連付けられている可能性がありますが、その目的は、環境やネットワークの添付ファイルを説明するのではなく、デバイスを識別することです。
Use of any identifier MUST only be allowed if it identifies a single Device at the time that location is determined. The LIS is responsible for ensuring that location information is correct for the Device, which includes ensuring that the identifier is uniquely attributable to the Device.
識別子の使用は、その場所が決定されたときに単一のデバイスを識別する場合にのみ許可する必要があります。LISは、識別子がデバイスに一意に起因することを保証することを含む、デバイスに対して位置情報が正しいことを確認する責任があります。
Some identifiers can be either temporary or could potentially identify multiple Devices. Identifiers that are transient or ambiguous could be exploited by an attacker to either gain information about another Device or to coerce the LIS into producing misleading information.
一部の識別子は、一時的なものであるか、複数のデバイスを潜在的に識別することができます。一時的または曖昧な識別子は、攻撃者によって悪用されて、別のデバイスに関する情報を取得するか、LISを誤解を招く情報を生成するように強制することができます。
The identifiers described in this document MUST only be used where that identifier is used as the basis for location determination. Considerations relating to the use of identifiers for a Device requesting its own location are discussed in Section 5 of [RFC5687]; this section discusses use of identifiers for authorized third-party requests.
このドキュメントで説明されている識別子は、その識別子が位置決定の基礎として使用される場合にのみ使用する必要があります。独自の場所を要求するデバイスの識別子の使用に関する考慮事項については、[RFC5687]のセクション5で説明します。このセクションでは、承認されたサードパーティリクエストの識別子の使用について説明します。
It is tempting for a LIS implementation to allow alternative identifiers for convenience or some other perceived benefit. The LIS is responsible for ensuring that the identifier used in the request does not refer to a Device other than the one for which it determines location.
LISの実装が、利便性またはその他の知覚された利益のために代替識別子を許可するために魅力的です。LISは、リクエストで使用されている識別子が、場所を決定するデバイス以外のデバイスを参照しないことを確認する責任があります。
Some identifiers are always uniquely attributable to a single Device. However, other identifiers can have a different meaning to different entities on a network. This is especially true for IP addresses [RFC2101], but this can be true for other identifiers to varying degrees. Non-uniqueness arises from both topology (all network entities have a subjective view of the network) and time (the network changes over time).
一部の識別子は、常に単一のデバイスに一意に起因します。ただし、他の識別子は、ネットワーク上の異なるエンティティに対して異なる意味を持つことができます。これは特にIPアドレス[RFC2101]に当てはまりますが、これは他の識別子にさまざまな程度に当てはまる可能性があります。非一致は、両方のトポロジ（すべてのネットワークエンティティがネットワークの主観的なビューを持っている）と時間（ネットワークが時間の経過とともに変化する）から生じます。
Subjective views of the network mean that the identifier a requestor uses to refer to one physical entity could actually apply to a different physical entity when used in a different network context. Unless an authorized third-party requestor and LIS operate in the same network context, each could have a different subjective view of the meaning of the identifier.
ネットワークの主観的ビューは、リクエスト因子が1つの物理エンティティを参照するために使用する識別子が、異なるネットワークコンテキストで使用すると実際に異なる物理エンティティに適用できることを意味します。認定されたサードパーティの要求者とLISが同じネットワークコンテキストで動作しない限り、それぞれが識別子の意味について異なる主観的な見解を持つことができます。
Where subjective views differ, the third party receives information that is correct only within the network context of the LIS. The location information provided by the LIS is probably misleading: the requestor believes that the information relates to a different entity than it was generated for.
主観的なビューが異なる場合、サードパーティは、LISのネットワークコンテキスト内でのみ正しい情報を受け取ります。LISが提供する位置情報はおそらく誤解を招くものです。要求者は、情報が生成されたものとは異なるエンティティに関連していると考えています。
Authorization policy can be affected by a subjective network view if it is applied based on an identifier or if its application depends on identifiers. The subjective view presented to the LIS and Rule Maker need to agree for the two entities to understand policy on the same terms. For instance, it is possible that the LIS could apply the incorrect authorization policy if it selects the policy using a subjective identifier. Alternatively, it may use the correct policy but apply it incorrectly if subjective identifiers are used.
承認ポリシーは、識別子に基づいて適用される場合、またはそのアプリケーションが識別子に依存している場合、主観的なネットワークビューの影響を受ける可能性があります。LISおよびルールメーカーに提示された主観的な見解は、2つのエンティティが同じ条件でポリシーを理解するために同意する必要があります。たとえば、主観的識別子を使用してポリシーを選択した場合、LISが誤った承認ポリシーを適用できる可能性があります。または、正しいポリシーを使用する場合がありますが、主観的な識別子が使用される場合は誤って適用します。
In IP networks, network address translation (NAT) and other forms of address modification create network contexts. Entities on either side of the point where modification occurs have a different view of the network. Private use addresses [RFC1918] are the most easily recognizable identifiers that have limited scope.
IPネットワークでは、ネットワークアドレス変換（NAT）およびその他の形式のアドレス修正がネットワークコンテキストを作成します。変更が発生するポイントの両側のエンティティは、ネットワークの異なるビューを持っています。プライベート使用アドレス[RFC1918]は、範囲が限られている最も簡単に認識できる識別子です。
A LIS can be configured to recognize scenarios where the subjective view of a requestor or Rule Maker might not coincide with the view of the LIS. The LIS can either provide location information that takes the view of the requestor into account, or it can reject the request.
LISは、リクエスターまたはルールメーカーの主観的なビューがLISのビューと一致しないシナリオを認識するように構成できます。LISは、要求者のビューを考慮した位置情報を提供するか、リクエストを拒否することができます。
For instance, a LIS might operate within a network that uses a private address space, with NAT between that network and other networks. A third-party request that originates in an external network with an IP address from the private address space might not be valid -- it could be identifying an entity within another address space. The LIS can be configured to reject such requests, unless it knows by other means that the request is valid.
たとえば、LISは、そのネットワークと他のネットワークの間にNATがあるプライベートアドレススペースを使用するネットワーク内で動作する場合があります。プライベートアドレススペースからIPアドレスを持つ外部ネットワークに由来するサードパーティの要求は、有効ではない場合があります。別のアドレススペース内のエンティティを識別している可能性があります。LISは、リクエストが有効であることを他の手段で知らない限り、そのような要求を拒否するように構成できます。
In the same example, the requestor might include an address from the external space in an attempt to identify a host within the network. The LIS could use knowledge about how the external address is mapped to a private address, if that mapping is fixed, to determine an appropriate response.
同じ例では、要求者は、ネットワーク内のホストを識別しようとする外部スペースからのアドレスを含めることができます。LISは、適切な応答を決定するために、マッピングが修正されている場合、外部アドレスがプライベートアドレスにマッピングされる方法に関する知識を使用できます。
The residential gateway scenario in Section 3.1 of [RFC5687] is a particular example of where a subjective view is permitted. The LIS knowingly provides Devices on the remote side of the residential gateway with location information. The LIS provides location information with appropriate uncertainty to allow for the fact that the residential gateway serves a small geographical area.
[RFC5687]のセクション3.1の住宅ゲートウェイシナリオは、主観的なビューが許可されている場所の特別な例です。LISは、住宅のゲートウェイの遠隔側にあるデバイスを故意に提供しています。LISは、住宅の玄関口が小さな地理的領域を提供するという事実を可能にするための適切な不確実性を備えた場所情報を提供します。
Some identifiers are temporary and can, over the course of time, be assigned to different physical entities. An identifier that is reassigned between the time that a request is formulated by a requestor and when the request is received by the LIS causes the LIS to locate a different entity than the requestor intended. The response from the LIS might be accurate, but the request incorrectly associates this information with the wrong subject.
一部の識別子は一時的なものであり、時間の経過とともに異なる物理エンティティに割り当てることができます。リクエストが要求者によって策定されるまでに再割り当てされた識別子は、LISによってリクエストが受信されたときに、LISがリクエストターが意図したものとは異なるエンティティを見つけます。LISからの応答は正確かもしれませんが、リクエストはこの情報を間違った主題と誤って関連付けます。
A LIS should be configured with information about any potentially temporary identifiers. It can use this information to identify when changes have occurred. A LIS must not provide location information if the identifier it uses might refer to a different Device. If an identifier might have been reassigned recently, or it is likely to be reassigned, it is not suitable as an identifier.
lisは、潜在的に一時的な識別子に関する情報で構成する必要があります。この情報を使用して、変更がいつ発生したかを識別できます。使用する識別子が別のデバイスを参照する場合がある場合、LISは位置情報を提供してはなりません。識別子が最近再割り当てされた可能性がある場合、または再割り当てされる可能性が高い場合、識別子として適していません。
It's possible that some degree of uncertainty could persist where identifiers are reassigned frequently; the extent to which errors arising from using transient identifiers are tolerated is a matter for local policy.
識別子が頻繁に再割り当てされる場合、ある程度の不確実性が持続する可能性があります。過渡識別子を使用することから生じるエラーが許容される程度は、ローカルポリシーの問題です。
Several of the identifiers in this document are used to identify a network interface. A Device can have multiple network interfaces. Uniquely identifying any network interface is assumed to be sufficient to identify the Device. When a network interface is identified, the goal is to identify the Device that is immediately attached to the network interface.
このドキュメントのいくつかの識別子は、ネットワークインターフェイスを識別するために使用されます。デバイスには、複数のネットワークインターフェイスを持つことができます。ネットワークインターフェイスを一意に識別することは、デバイスを識別するのに十分であると想定されています。ネットワークインターフェイスが識別されると、目標は、ネットワークインターフェイスにすぐに接続されているデバイスを識別することです。
Most network interfaces remain physically attached to a particular Device, though a network interface might be physically separable from the Device. By identifying a network interface, any Device that is intended to be identified could change.
ほとんどのネットワークインターフェイスは、特定のデバイスに物理的に接続されたままですが、ネットワークインターフェイスはデバイスから物理的に分離可能である可能性があります。ネットワークインターフェイスを識別することにより、識別することを目的としたデバイスが変更される可能性があります。
XML elements are used to express the Device identity. The "device" element is used as a general container for identity information. This document defines a basic set of identifiers. An example HELD request, shown in Figure 1, includes an IP version 4 address.
XML要素は、デバイスのアイデンティティを表現するために使用されます。「デバイス」要素は、ID情報の一般的なコンテナとして使用されます。このドキュメントは、識別子の基本セットを定義します。図1に示す例のあるリクエストの例には、IPバージョン4アドレスが含まれています。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType exact="true">geodetic</locationType>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.5</ip>
</device>
</locationRequest>
Figure 1: HELD Request with Device Identity
図1：デバイスのアイデンティティを備えた保留要求
A LIS that supports this specification echoes the "device" element in a successful HELD response, including the identifiers that were used as the basis for location determination. Absence of this indication means that the location information was generated using the source IP address in the request.
この仕様をサポートするLISは、位置決定の基礎として使用された識別子を含む、成功した保有応答の「デバイス」要素をエコーします。この表示がないということは、リクエスト内のソースIPアドレスを使用して位置情報が生成されたことを意味します。
A "badIdentifier" HELD error code indicates that the requestor is not authorized to use that identifier or that the request contains an identifier that is badly formatted or not supported by the LIS. This code is registered in Section 7.3.
「badididentifier」にあるエラーコードは、要求者がその識別子を使用することを許可されていないことを示しています。このコードはセクション7.3に登録されています。
If the LIS requires an identifier that is not provided in the request, the desired identifiers MAY be identified in the HELD error response, using the "requiredIdentifiers" element. This element contains a list of XML qualified names [W3C.REC-xml-names11-20060816] that identify the identifier elements required by the LIS. Namespace prefix bindings for the qualified names are taken from document context. Figure 2 shows an example error indicating that the requestor needs to include a media access control (MAC) address (Section 3.2) and IP address (Section 3.1) if the request is to succeed.
LISがリクエストで提供されていない識別子を必要とする場合、「必須条件」要素を使用して、希望の識別子を保有エラー応答で識別することができます。この要素には、LISが必要とする識別子要素を識別するXML適格名[w3c.rec-xml-names11-20060816]のリストが含まれています。適格な名前の名前空間プレフィックスバインディングは、ドキュメントコンテキストから取得されます。図2は、リクエストが成功するためにリクエスト装置がメディアアクセスコントロール（MAC）アドレス（セクション3.2）とIPアドレス（セクション3.1）を含める必要があることを示すエラーの例を示しています。
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="badIdentifier">
<message xml:lang="en">MAC address required</message>
<requiredIdentifiers
xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
mac ip
</requiredIdentifiers>
</error>
Figure 2: HELD Error Requesting Device Identifiers
図2：デバイス識別子を要求するヘルドエラー
A limited selection of identifiers are included in this document. The basic Device identity schema allows for the inclusion of elements from any namespace; therefore, additional elements can be defined using different XML namespaces.
このドキュメントには、限られた識別子が含まれています。基本的なデバイスIDスキーマでは、任意の名前空間から要素を含めることができます。したがって、追加の要素は、異なるXMLネームスペースを使用して定義できます。
The "ip" element can express a Device identity as an IP address ([RFC0791], [RFC4291]). The "v" attribute identifies the IP version with a single hexadecimal digit. The element uses the textual format specific to the indicated IP version. The textual format for IP version 4 and version 6 addresses MUST conform to the grammar defined in [RFC3986] ("IPv4address" and "IPv6address", respectively). IP version 6 addresses SHOULD conform to the formatting conventions in [RFC5952].
「IP」要素は、デバイスのIDをIPアドレスとして表現できます（[RFC0791]、[RFC4291]）。「V」属性は、単一の16進数桁でIPバージョンを識別します。要素は、指定されたIPバージョンに固有のテキスト形式を使用します。IPバージョン4およびバージョン6アドレスのテキスト形式は、[RFC3986]（「IPv4Address」と「IPv6Address」）で定義されている文法に準拠する必要があります。IPバージョン6アドレスは、[RFC5952]のフォーマット規則に準拠する必要があります。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:db8::1:ea7:fee1:d1e</ip>
</device>
In situations where location configuration does not require additional identifiers, using an IP address as an identifier enables authorized third-party requests.
IPアドレスを識別子として使用すると、場所構成が追加の識別子を必要としない状況では、認定されたサードパーティ要求を可能にします。
The MAC address used by network interfaces attached to the IEEE LAN [IEEE802]. A MAC address is a unique sequence that is either assigned at the time of manufacture of the interface, or assigned by a local administrator. A MAC address is an appropriate identifier for the Device that uses the network interface as long as the two remain together (see Section 2.1.3).
IEEE LAN [IEEE802]に接続されたネットワークインターフェイスで使用されるMACアドレス。MACアドレスは、インターフェイスの製造時に割り当てられるか、ローカル管理者によって割り当てられる一意のシーケンスです。MACアドレスは、2つが一緒に残っている限り、ネットワークインターフェイスを使用するデバイスの適切な識別子です（セクション2.1.3を参照）。
A MAC address can be represented as a MAC-48, EUI-48, or EUI-64 address ([IEEE802], or an extended unique identifier [EUI64]) using the hexadecimal representation defined in [IEEE802].
MACアドレスは、[IEEE802]で定義された六方項表現を使用して、MAC-48、EUI-48、またはEUI-64アドレス（[IEEE802]、または拡張された一意の識別子[EUI64]）として表すことができます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<mac>A0-12-34-56-78-90</mac>
</device>
A locally assigned MAC address is not guaranteed to be unique outside the administrative domain where it is assigned. Locally assigned MAC addresses can only be used within this domain.
ローカルに割り当てられたMACアドレスは、割り当てられている管理ドメインの外で一意であることは保証されていません。ローカルに割り当てられたMacアドレスは、このドメイン内でのみ使用できます。
A host might only be known by a flow of packets that it is sending or receiving. On its own, a port number is insufficient to uniquely identify a single host. In combination with an IP address, a port number can be used to uniquely identify a Device in some circumstances.
ホストは、送信または受信しているパケットのフローによってのみ知られている場合があります。単独では、ポート番号が1つのホストを一意に識別するには不十分です。IPアドレスと組み合わせて、ポート番号を使用して、状況によってはデバイスを一意に識別できます。
Use of a particular port number can be transient; often significantly more than use of any given IP address. However, widespread use of network address translation (NAT) means that some Devices cannot be uniquely identified by IP address alone. An individual Device might be identified by a flow of packets that it generates. Providing that a LIS has sufficient knowledge of the mappings used by the NAT, an individual target on the remote side of the NAT might be able to be identified uniquely.
特定のポート番号の使用は一時的です。多くの場合、特定のIPアドレスの使用よりも大幅に多く。ただし、ネットワークアドレス変換（NAT）の広範な使用は、一部のデバイスをIPアドレスのみで一意に識別できないことを意味します。個々のデバイスは、生成するパケットのフローによって識別される場合があります。LISがNATが使用するマッピングについて十分な知識を持っていることを提供すると、NATのリモート側の個々のターゲットが一意に識別できる可能性があります。
Port numbers are defined for UDP [RFC0768], TCP [RFC0793], SCTP [RFC4960], and DCCP [RFC4340].
ポート番号は、UDP [RFC0768]、TCP [RFC0793]、SCTP [RFC4960]、およびDCCP [RFC4340]で定義されています。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.75</ip>
<udpport>51393</udpport>
</device>
Use of port numbers is especially reliant on the value remaining consistent over time.
ポート番号の使用は、特に時間の経過とともに一貫している値に依存しています。
A Network Access Identifier (NAI) [RFC4282] is an identifier used in network authentication in a range of networks. The identifier establishes a user identity within a particular domain. Often, network services use an NAI in relation to location records, tying network access to user authentication and authorization.
ネットワークアクセス識別子（NAI）[RFC4282]は、さまざまなネットワークのネットワーク認証で使用される識別子です。識別子は、特定のドメイン内でユーザーIDを確立します。多くの場合、ネットワークサービスは、ロケーションレコードに関連してNAIを使用し、ユーザー認証と認証へのネットワークアクセスを結びます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<nai>user@example.net</nai>
</device>
The formal grammar for NAI [RFC4282] permits sequences of octets that are not valid UTF-8 [RFC3629] sequences. These sequences cannot be expressed using XML. Therefore, this expression of NAI permits escaping. Sequences of octets that do not represent a valid UTF-8 encoding can be expressed using a backslash ('\') followed by two case-insensitive hexadecimal digits representing the value of a single octet.
NAI [RFC4282]の正式な文法は、有効なUTF-8 [RFC3629]シーケンスのシーケンスを許可します。これらのシーケンスは、XMLを使用して表現することはできません。したがって、このNAIの表現は逃げることを許可します。有効なUTF-8エンコーディングを表すオクテットのシーケンスは、単一のオクテットの値を表す2つのケースに感受性のある六肢数字を使用して、バックスラッシュ（ '\'）を使用して表現できます。
The canonical representation of an NAI is the sequence of octets that is produced from the concatenation of UTF-8 encoded sequences of unescaped characters and octets derived from escaped components. The resulting sequence of octets MUST conform to the constraints in [RFC4282].
NAIの標準表現は、逃げられたコンポーネントに由来するUNESCAPED文字とオクテットのUTF-8エンコードされたシーケンスの連結から生成されるオクテットのシーケンスです。結果のオクテットのシーケンスは、[RFC4282]の制約に準拠する必要があります。
For example, the NAI "f<U+FC>\<0xFF>@bar.com" that includes the UTF-8 encoded u-umlaut character (U+FC) and an invalid UTF-8 octet (0xFF) might be represented as "f\c3\bc\5c\90@bar.com", though the u-umlaut character might be included directly.
たとえば、UTF-8エンコードされたU-Umlaut文字（U FC）と無効なUTF-8オクテット（0xff）を含むNai "f <u fc> \ <0xff>@bar.com"は、」として表される場合があります。f \ c3 \ bc \ 5c \ 90@bar.com "ですが、U-Umlautの文字は直接含まれる場合があります。
An NAI in WiMAX is uniquely attributable to a single Device at any one time. An NAI either identifies a Device or a service subscription, neither of which can have multiple active sessions.
WimaxのNAIは、一度に単一のデバイスに独自に起因しています。NAIは、デバイスまたはサービスサブスクリプションを識別しますが、どちらも複数のアクティブセッションを持つことはできません。
In a WiMAX network, an IP address is not sufficient information for a LIS to locate a Device. The following procedure relies on an NAI to identify the Device. This procedure and the messages and parameters is relies upon are defined in [WiMAX-T33-110-R015v01-B].
WIMAXネットワークでは、IPアドレスはLISがデバイスを見つけるのに十分な情報ではありません。次の手順は、デバイスを識別するためにNAIに依存しています。この手順とメッセージとパラメーターは、[WIMAX-T33-110-R015V01-B]で定義されています。
Location requests in a WiMAX network always require the inclusion of an NAI. However, if a LIS receives a request that does not come from an authenticated and authorized third-party requestor, it can treat this request as a location configuration request.
WIMAXネットワーク内のロケーションリクエストには、常にNAIを含める必要があります。ただし、LISが認証された認定されたサードパーティリクエストターから生じないリクエストを受信した場合、このリクエストをロケーション構成要求として扱うことができます。
After receiving a location request that includes an NAI, the LIS sends a "Location-Requestor-Authentication-Protocol" access request message to the Authentication, Authorization, and Accounting (AAA) server. This request includes an "MS-Identity-Assertion" parameter containing the NAI.
NAIを含むロケーションリクエストを受信した後、LISは「ロケーション - リクエスト担当者 - 承認 - コール」アクセス要求メッセージを認証、承認、および会計（AAA）サーバーに送信します。このリクエストには、NAIを含む「MS-IDIDITION-ASSERTION」パラメーターが含まれます。
The AAA server consults network policy, and if the request is permitted, the response includes the IP address that is currently assigned to the Device. If this IP address matches the source IP address of the HELD location request, the location request can be authorized under the LCP policy (see Section 4.1). Otherwise, the request must be treated as a third-party request.
AAAサーバーはネットワークポリシーに相談し、要求が許可されている場合、応答には現在デバイスに割り当てられているIPアドレスが含まれます。このIPアドレスがHelld Location RequestのソースIPアドレスと一致する場合、ロケーションリクエストはLCPポリシーの下で承認できます（セクション4.1を参照）。それ以外の場合、リクエストはサードパーティのリクエストとして扱わなければなりません。
This relies on the same protections against IP address spoofing that are required by [RFC5985]. In addition, the request made of the AAA uses either Diameter [RFC3588] or RADIUS [RFC2865], and therefore relies on the protections provided by those protocols. In order to rely on the access request, the AAA server MUST be authenticated to be a trusted entity for the purpose of providing a link between the NAI and IP address. The AAA protocol MUST also provide protection from modification and replay attacks to ensure that data cannot be altered by an attacker.
これは、[RFC5985]で必要なIPアドレススプーフィングに対する同じ保護に依存しています。さらに、AAAで行われた要求は、直径[RFC3588]またはRADIUS [RFC2865]のいずれかを使用しているため、これらのプロトコルによって提供される保護に依存しています。アクセスリクエストに依存するために、AAAサーバーは、NAIアドレスとIPアドレスの間にリンクを提供する目的で、信頼できるエンティティになるように認証されている必要があります。また、AAAプロトコルは、攻撃者がデータを変更できないことを確認するために、変更およびリプレイ攻撃からの保護も提供する必要があります。
A Device can be identified by a URI [RFC3986]. Any URI can be used providing that the requestor and LIS have a common understanding of the semantics implied by use of the URI.
デバイスはURI [RFC3986]によって識別できます。RequestorとLISがURIの使用によって暗示されるセマンティクスを一般的に理解していることを提供するために、すべてのURIを使用できます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>sip:user@example.net;gr=kjh29x97us97d</uri>
</device>
Particular care needs to be taken in ensuring that a particular URI only refers to a single Device. In many cases, a URI can resolve to multiple destinations. For example, a SIP address of record URI can correspond to a service subscription rather than a single Device.
特定のURIが単一のデバイスのみを指すようにするために、特定の注意を払う必要があります。多くの場合、URIは複数の宛先に解決できます。たとえば、レコードURIのSIPアドレスは、単一のデバイスではなくサービスサブスクリプションに対応できます。
A "tel:" URI [RFC3966] can be used to identify a Device by telephone number:
「Tel：」URI [RFC3966]を使用して、電話番号でデバイスを識別できます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>tel:800-555-1111;extension=1234;phone-context=+1</uri>
</device>
A fully qualified domain name can be used as the basis for identification using the "fqdn" element.
完全に適格なドメイン名は、「FQDN」要素を使用した識別の基礎として使用できます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<fqdn>host.example.net</fqdn>
</device>
This domain name slot, which is aware of Internationalized Domain Names for Applications (IDNA) [RFC5890], is formed from any sequence of valid U-labels or NR-LDH-labels.
このドメイン名スロットは、アプリケーション（IDNA）[RFC5890]の国際化ドメイン名を認識しており、有効なUラベルまたはNR-LDHラベルの任意のシーケンスから形成されます。
A domain name does not always correspond to a single IP address or host. If this is the case, a domain name is not a suitable identifier.
ドメイン名は、常に単一のIPアドレスまたはホストに対応するとは限りません。この場合、ドメイン名は適切な識別子ではありません。
A range of different forms of mobile station identifiers are used for different cellular telephony systems. Elements are defined for these identifiers. The following identifiers are defined: msisdn: The Mobile Station International Subscriber Dial Number (MSISDN) [E.213] is an E.164 number [E.164] between 6 and 15 digits long.
さまざまな形式のモバイルステーション識別子がさまざまなセルラーテレフォニーシステムに使用されています。これらの識別子の要素は定義されています。次の識別子が定義されています：MSISDN：モバイルステーション国際サブスクライバーダイヤル番号（MSISDN）[E.213]は、長さ6〜15桁のE.164番号[E.164]です。
imsi: The International Mobile Subscriber Identity (IMSI) [TS.3GPP.23.003] is an identifier associated with all GSM (Global System for Mobile Communications) and UMTS (Universal Mobile Telecommunications System) mobile subscribers between 6 and 15 digits in length.
IMSI：国際的なモバイル加入者ID（IMSI）[Ts.3GPP.23.003]は、長さ6〜15桁のすべてのGSM（モバイル通信のグローバルシステム）およびUMTS（ユニバーサルモバイルテレコミュニケーションシステム）モバイルサブスクライバーに関連付けられた識別子です。
imei: The International Mobile Equipment Identifier (IMEI) [TS.3GPP.23.003] is a unique device serial number up to 15 digits long.
IMEI：国際的なモバイル機器識別子（IMEI）[Ts.3GPP.23.003]は、最大15桁のユニークなデバイスシリアル番号です。
min: The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a 10-digit unique number assigned to CDMA handsets.
MIN：モバイル識別番号（MIN）[TIA.EIA.IS-2000-6]は、CDMAハンドセットに割り当てられた10桁の一意の番号です。
mdn: The Mobile Directory Number (MDN) is an E.164 number [E.164], with usage similar to MSISDN.
MDN：モバイルディレクトリ番号（MDN）はE.164番号[e.164]で、MSISDNと同様の使用法があります。
Each identifier contains a string of decimal digits with a length as specified.
各識別子には、指定された長さの小数点図が含まれています。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<msisdn>11235550123</msisdn>
</device>
The Dynamic Host Configuration Protocol (DHCP) uses a binary identifier for its clients. The DHCP Unique Identifier (DUID) is expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The "duid" element includes the binary value of the DUID expressed in hexadecimal.
動的ホスト構成プロトコル（DHCP）は、クライアントにバイナリ識別子を使用します。DHCP一意の識別子（DUID）は、DHCPV4のオプション61（[RFC4361]を参照）またはDHCPV6のオプション1で表現され、[RFC3315]のセクション9で定義されている形式に従います。「DUID」要素には、16進数で表されるDUIDのバイナリ値が含まれます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<duid>1234567890AaBbCcDdEeFf</duid>
</device>
Location configuration protocols can make use of an authorization model known as "LCP policy", which permits only Targets to be the recipients of their own locations. In effect, an LCP server (that is, the LIS) follows a single-rule policy that states that the Target is the only authorized Location Recipient.
位置構成プロトコルは、「LCPポリシー」として知られる承認モデルを使用することができます。これは、ターゲットのみが自分の場所の受信者であることのみを許可します。実際には、LCPサーバー（つまり、LIS）は、ターゲットが唯一の承認された場所の受信者であると述べる単一ルールポリシーに従います。
The security and privacy considerations of the base HELD protocol [RFC5985] are applicable. However, the considerations relating to return routability do not apply to third-party requests. Return routability may also not apply to requests from Targets for their own location, depending on the anti-spoofing mechanisms employed for the identifier.
ベース保有プロトコル[RFC5985]のセキュリティとプライバシーの考慮事項が適用されます。ただし、返品ルーティング性に関する考慮事項は、サードパーティのリクエストには適用されません。識別子に採用されているスプーフィング防止メカニズムに応じて、ターゲットからのターゲットからのリクエストには、返品ルーティング可能性が適用されない場合があります。
When a Target uses identity extensions to obtain its own location, HELD can no longer be considered an LCP. The authorization policy that the LIS uses to respond to these requests must be provisioned by one or more Rule Makers.
ターゲットがID拡張機能を使用して独自の位置を取得する場合、HoldはLCPと見なすことができなくなります。LISがこれらの要求に応答するために使用する認可ポリシーは、1つ以上のルールメーカーによってプロビジョニングされなければなりません。
In the case that the LIS exclusively provides Targets with their own locations, the LIS can still be said to be following the "LCP policy". The "LCP policy" concept and further security and privacy considerations can be found in [GEOPRIV-ARCH].
LISが独自の場所をターゲットのみに提供する場合、LISは「LCPポリシー」に従っていると言えます。「LCPポリシー」の概念とさらなるセキュリティとプライバシーの考慮事項は、[Geopriv-Arch]にあります。
The spoofing protections provided when using HELD with identity extensions to provide Targets with their own locations differ from the protections inherent in an LCP. For an LCP, return routability is considered sufficient protection against spoofing. For a similar policy to be used, specific measures MUST be defined to protect against spoofing of the alternative identifier. This document defines this for an NAI when used in WiMAX networks (see Section 3.4.1), but for no other identifier.
ID拡張機能を使用してターゲットを提供する場合に提供されるスプーフィング保護は、LCPに固有の保護とは異なります。LCPの場合、リターンルーティング可能性はスプーフィングに対する十分な保護と見なされます。同様のポリシーを使用するには、代替識別子のスプーフィングから保護するために特定の測定値を定義する必要があります。このドキュメントでは、WIMAXネットワークで使用された場合のNAIに対してこれを定義します（セクション3.4.1を参照）が、他の識別子はありません。
A Rule Maker might require an assurance that the identifier is owned by the requestor. Any multi-stage verification process that includes a return routability test cannot provide any stronger assurance than return routability alone; therefore, policy might require the use of additional, independent methods of verification.
ルールメーカーには、識別子がリクエスターが所有しているという保証が必要になる場合があります。返品ルー上のテストを含むマルチステージ検証プロセスは、返品ルーチャビリティだけではより強力な保証を提供することはできません。したがって、ポリシーには、追加の独立した検証方法の使用が必要になる場合があります。
Care is required where a direct one-to-one relationship between requestor and Device identity does not exist. If identifiers are not uniquely attributable to a single Device, the use of HELD identity extensions to provide Targets with their own locations could be exploited by an attacker.
要求者とデバイスのIDの間に直接的な1対1の関係が存在しない場合は、注意が必要です。識別子が単一のデバイスに一意に起因していない場合、ターゲットを自分の場所でターゲットに提供するために保持されているID拡張機能を使用することは、攻撃者によって悪用される可能性があります。
It might be possible in some networks to establish multiple concurrent sessions using the same credentials. For instance, Devices with different MAC addresses might be granted concurrent access to a network using the same NAI. It is not appropriate to provide Targets with their own locations based on the NAI in this case. Neither is it appropriate to authenticate a Device using NAI and allow that Device to provide an unauthenticated MAC address as a Device identifier, even if the MAC address is registered to the NAI. The MAC address potentially identifies a different Device than the one that is making the request. The correct way of gaining authorization is to establish a policy that permits this particular request as a third-party request.
一部のネットワークでは、同じ資格情報を使用して複数の同時セッションを確立することが可能かもしれません。たとえば、MACアドレスが異なるデバイスには、同じNAIを使用してネットワークへの同時アクセスが付与される場合があります。この場合、NAIに基づいてターゲットに独自の場所を提供することは適切ではありません。NAIを使用してデバイスを認証し、MacアドレスがNAIに登録されていても、そのデバイスがデバイス識別子として認定されていないMACアドレスを提供できるようにすることも適切ではありません。Macアドレスは、リクエストを行っているデバイスとは異なるデバイスを識別する可能性があります。許可を得る正しい方法は、この特定の要求をサードパーティの要求として許可するポリシーを確立することです。
Section 3.4.1 discusses the implications of using an NAI as an identifier for location requests made of a LIS serving a WiMAX network. Additional security considerations are discussed in [WiMAX-T33-110-R015v01-B].
セクション3.4.1では、WIMAXネットワークを提供するLISで作成された場所リクエストの識別子としてNAIを使用することの意味について説明します。追加のセキュリティ上の考慮事項については、[WIMAX-T33-110-R015V01-B]で説明します。
The "LCP policy" does not allow requests made by third parties. If a LIS permits requests from third parties using Device identity, it assumes the rule of a Location Server (LS). As a Location Server, the LIS MUST explicitly authorize requests according to the policies that are provided by Rule Makers, including the Target. The LIS MUST also authenticate requestors according to any agreed-upon authorization policy.
「LCPポリシー」は、第三者による要求を許可していません。LISがデバイスIDを使用して第三者からの要求を許可する場合、ロケーションサーバー（LS）のルールを想定します。ロケーションサーバーとして、LISは、ターゲットを含むルールメーカーによって提供されるポリシーに従って、要求を明示的に承認する必要があります。また、LISは、合意された認可ポリシーに従って要求者を認証する必要があります。
An organization that provides a LIS that allows third-party requests must provide a means for a Rule Maker to specify authorization policies as part of the LIS implementation (e.g, in the form of access control lists). Authorization must be established before allowing third-party requests for the location of any Target. Until an authorization policy is established, the LIS MUST reject requests by third parties (that is, the default policy is "deny all").
サードパーティのリクエストを許可するLISを提供する組織は、ルールメーカーがLIS実装の一部として認証ポリシーを指定する手段を提供する必要があります（たとえば、アクセス制御リストの形式）。ターゲットの場所に対するサードパーティの要求を許可する前に、承認を確立する必要があります。許可ポリシーが確立されるまで、LISは第三者による要求を拒否しなければなりません（つまり、デフォルトのポリシーは「すべてを否定します」）。
When the LIS is operated by an access network, the relationship between the Target and the LIS can be transient. As the Target is a potential Rule Maker, this presents a problem. However, the process of establishing network access usually results in a form of agreement between the Target and the network provider. This process offers a natural vehicle for establishing location privacy policies. Establishing authorization policy might be a manual process, an explicit part of the terms of service for the network, or an automated system that accepts formal authorization policies (see [RFC4745] and [RFC4825]). This document does not mandate any particular mechanism for establishing an authorization policy.
LISがアクセスネットワークによって動作する場合、ターゲットとLISの関係は一時的になります。ターゲットは潜在的なルールメーカーであるため、これは問題を提示します。ただし、ネットワークアクセスを確立するプロセスは、通常、ターゲットとネットワークプロバイダーとの間に一致の形をとることができます。このプロセスは、場所のプライバシーポリシーを確立するための自然な手段を提供します。認可ポリシーの確立は、手動プロセス、ネットワークの利用規約の明示的な部分、または正式な承認ポリシーを受け入れる自動システムである可能性があります（[RFC4745]および[RFC4825]を参照）。このドキュメントは、承認ポリシーを確立するための特定のメカニズムを義務付けていません。
The security considerations in [RFC5985] describe the use of Transport Layer Security (TLS) [RFC5246] for server authentication, confidentiality, and protection from modification. These protections apply to both Target requests for their own locations and requests made by third parties.
[RFC5985]のセキュリティ上の考慮事項は、サーバー認証、機密性、および変更からの保護のための輸送層セキュリティ（TLS）[RFC5246]の使用について説明しています。これらの保護は、独自の場所の両方のターゲットリクエストと、第三者が行った要求に適用されます。
All HELD requests containing identity MUST be authenticated by the LIS. How authentication is accomplished and what assurances are desired is a matter for policy.
IDを含むすべての保有要求は、LISによって認証される必要があります。認証がどのように達成され、保証が望ましいものはポリシーの問題です。
The base HELD protocol uses return reachability of an IP address implied by the requestor being able to successfully complete a TCP handshake. It is RECOMMENDED that any means of authentication provide at least this degree of assurance. For requests that include Device identity, the requestor MUST support HTTP digest authentication [RFC2617]. Unauthenticated location requests containing Device identity can be challenged with an HTTP 401 (Unauthorized) response or rejected with an HTTP 403 (Forbidden) response.
ベース保有プロトコルは、リクエスト担当者がTCPハンドシェイクを正常に完了できることを暗示するIPアドレスの返品到達可能性を使用します。認証の手段は、少なくともこの程度の保証を提供することをお勧めします。デバイスのIDを含むリクエストの場合、リクエスタはHTTPダイジェスト認証をサポートする必要があります[RFC2617]。デバイスのアイデンティティを含む未承認の位置要求は、HTTP 401（不正）応答で挑戦するか、HTTP 403（禁止）応答で拒否されます。
HELD [RFC5985] does not mandate that Devices implement authentication. A LIS SHOULD NOT send a HTTP 401 response if the Device does not include Device identity.
[RFC5985]は、デバイスが認証を実装することを義務付けていません。デバイスにデバイスのIDが含まれていない場合、LISはHTTP 401応答を送信しないでください。
Transient and ambiguous identifiers can be exploited by malicious requests and are not suitable as a basis for identifying a Device. Section 2.1 provides further discussion on this subject.
一時的であいまいな識別子は、悪意のあるリクエストによって悪用される可能性があり、デバイスを識別するための基礎として適していません。セクション2.1は、この主題に関するさらなる議論を示しています。
Identifier transience can lead to incorrect location information being provided. An attacker could exploit the use of transient identifiers. In this attack, the attacker either knows of a re-allocation of that identifier or is able to force the identifier to be re-allocated during the processing of the request.
識別子のトランジエンスは、誤った位置情報が提供されていることにつながる可能性があります。攻撃者は、一時的な識別子の使用を活用できます。この攻撃では、攻撃者はその識別子の再割り当てを知っているか、リクエストの処理中に識別子を強制的に再割り当てさせることができます。
An attacker could use this to acquire location information for another Device or to coerce the LIS to lie on its behalf if this re-allocation occurs between the time where authorization is granted and location information is granted.
攻撃者はこれを使用して、別のデバイスの位置情報を取得したり、許可が付与されたり位置情報が付与されている間にこの再配分が発生した場合にLISを強制して嘘をつくことができます。
Ambiguous identifiers present a similar problem. An attacker could legitimately gain authorization to use a particular identifier. Since an ambiguous identifier potentially refers to multiple Devices, if authorization is granted for one of those Devices, an attacker potentially gains access to location information for all of those Devices.
あいまいな識別子も同様の問題を提示します。攻撃者は、特定の識別子を使用する許可を正当に獲得できます。あいまいな識別子は複数のデバイスを潜在的に指すため、それらのデバイスのいずれかに対して許可が付与された場合、攻撃者はそれらのすべてのデバイスの位置情報へのアクセスを潜在的に獲得する可能性があります。
Requests made by a Device for its own location are covered by the same set of protections offered by HELD. These requests might be authorized under a policy similar to the "LCP policy" that permits a Target access to location information about itself.
独自の場所のデバイスによって作成されたリクエストは、保有によって提供される同じ保護セットでカバーされています。これらの要求は、それ自体に関する位置情報へのターゲットアクセスを許可する「LCPポリシー」と同様のポリシーに基づいて承認される場合があります。
Identity information provided by the Device is private data that might be sensitive. The Device provides this information in the expectation that it assists the LIS in providing the Device a service. The LIS MUST NOT use identity information for any other purpose other than serving the request that includes that information.
デバイスが提供するID情報は、感受性のあるプライベートデータです。このデバイスは、この情報を、LISがデバイスにサービスを提供するのを支援することを期待して提供します。LISは、その情報を含むリクエストを提供する以外の他の目的のためにID情報を使用してはなりません。
Requests from third parties have the same requirements for server authentication, confidentiality, and protection from modification as Target requests for their own locations. However, because the third party needs to be authorized, the requestor MUST be authenticated by the LIS. In addition, third-party requests MUST be explicitly authorized by a policy that is established by a Rule Maker.
サードパーティからの要求には、自分の場所のターゲット要求と同じように、サーバー認証、機密性、および変更からの保護に関する同じ要件があります。ただし、第三者を承認する必要があるため、要求者はLISによって認証される必要があります。さらに、サードパーティの要求は、ルールメーカーによって確立されたポリシーによって明示的に承認されなければなりません。
More detail on the privacy implications of third-party requests are covered in Section 4.
サードパーティリクエストのプライバシーへの影響の詳細については、セクション4で説明しています。
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:id">
HELD Device Identity
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc6155.txt">
This document defines Device identity elements for HELD.
</xs:documentation>
</xs:annotation>
<xs:element name="device" type="id:deviceIdentity"/>
<xs:complexType name="deviceIdentity">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="requiredIdentifiers" type="id:qnameList"/>
<xs:simpleType name="qnameList">
<xs:list itemType="xs:QName"/>
</xs:simpleType>
<xs:element name="ip" type="id:ipAddress"/>
<xs:complexType name="ipAddress">
<xs:simpleContent>
<xs:extension base="xs:token">
<xs:attribute name="v" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="mac" type="id:macAddress"/>
<xs:simpleType name="macAddress">
<xs:restriction base="xs:token">
<xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="udpport" type="id:portNumber"/>
<xs:element name="tcpport" type="id:portNumber"/>
<xs:element name="sctpport" type="id:portNumber"/>
<xs:element name="dccpport" type="id:portNumber"/>
<xs:simpleType name="portNumber">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="nai" type="id:naiType"/>
<xs:simpleType name="naiType">
<xs:restriction base="xs:token">
<xs:pattern
value="([^\\]|\\[\dA-Fa-f]{2})*
(@([A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*\.)+
[A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*)?"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="fqdn" type="xs:token"/>
<xs:element name="duid" type="xs:hexBinary"/>
<xs:element name="msisdn" type="id:e164"/>
<xs:element name="imsi" type="id:e164"/>
<xs:element name="imei" type="id:digit15"/>
<xs:element name="min" type="id:digit10"/>
<xs:element name="mdn" type="id:e164"/>
<xs:simpleType name="digits">
<xs:restriction base="xs:token">
<xs:pattern value="[\d]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="e164">
<xs:restriction base="id:digit15">
<xs:minLength value="6"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit15">
<xs:restriction base="id:digits">
<xs:maxLength value="15"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="digit10">
<xs:restriction base="id:digits">
<xs:length value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
This document registers an XML namespace and schema with IANA in accordance with guidelines in [RFC3688].
このドキュメントは、[RFC3688]のガイドラインに従って、IANAを使用してXML名空間とスキーマを登録します。
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名空間「urn：ietf：xml：ns：geopriv：held：id」を登録します。
URI: urn:ietf:params:xml:ns:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).
登録者の連絡先：IETF、Geoprivワーキンググループ（geopriv@ietf.org）、James Winterbottom（james.winterbottom@andrew.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 Device Identity Parameters</title>
</head>
<body>
<h1>Namespace for HELD Device Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:id</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6155.txt">
RFC 6155</a>.</p>
</body>
</html>
END
This section registers an XML schema as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従ってXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).
登録者の連絡先：IETF、Geoprivワーキンググループ（geopriv@ietf.org）、James Winterbottom（james.winterbottom@andrew.com）。
Schema: The XML for this schema can be found as the entirety of Section 6 of this document.
スキーマ：このスキーマのXMLは、このドキュメントのセクション6全体として見つけることができます。
This section registers the "badIdentifier" error code in the IANA maintained "HELD Error Codes" sub-registry of the "Geopriv HTTP Enabled Location Delivery (HELD) Parameters" registry.
このセクションでは、IANAの「badidecidentifier」エラーコードが「保持されているエラーコード」を維持します。
badIdentifier This error code indicates that a Device identifier used in the HELD request was either: not supported by the LIS, badly formatted, or not one for which the requestor was authorized to make a request.
badididentifierこのエラーコードは、保有リクエストで使用されたデバイス識別子が次のとおりであることを示しています。LISによってサポートされておらず、ひどくフォーマットされていないか、要求者が要求を行うことを許可されていなかったものではありません。
The National Emergency Number Association (NENA) VoIP location working group provided assistance in the definition of the schema used in this document. Special thanks go to Barbara Stark, Guy Caron, Nadine Abbott, Jerome Grenier, and Martin Dawson. Bob Sherry provided input on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for providing further corrections. Bernard Aboba provided excellent feedback on use cases and the security model; Bernard, along with Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis provided motivation for the protocol port parameters. Marc Linsner and Alissa Cooper provided guidance and text (respectively) that greatly clarified the discussion relating to LCPs. Thanks to Jon Peterson and Cullen Jennings for forcing this to be practical.
National Emartical Number Association（Nena）VoIP Location Working Groupは、この文書で使用されているスキーマの定義に支援を提供しました。バーバラ・スターク、ガイ・キャロン、ナディーン・アボット、ジェローム・グレニエ、マーティン・ドーソンに感謝します。ボブ・シェリーは、URISの使用に関する情報を提供しました。さらなる修正を提供してくれたAdam MuhlbauerとEddy Corbettに感謝します。バーナード・アボバは、ユースケースとセキュリティモデルに関する優れたフィードバックを提供しました。バーナードは、アラン・デコクとともに、NAISの問題の解決を支援しました。レイ・ベリスは、プロトコルポートパラメーターの動機を提供しました。Marc LinsnerとAlissa Cooperは、LCPに関連する議論を大いに明らかにしたガイダンスとテキスト（それぞれ）を提供しました。Jon PetersonとCullen Jenningsがこれを強制してくれたことに感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[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月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361] Lemon、T。およびB. Sommerfeld、「動的ホスト構成プロトコルバージョン4（DHCPV4）のノード固有のクライアント識別子」、RFC 4361、2006年2月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP対応の位置配信（保有）」、RFC 5985、2010年9月。
[W3C.REC-xml-names11-20060816] Hollander, D., Tobin, R., Layman, A., and T. Bray, "Namespaces in XML 1.1 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[W3C.REC-XML-NAMES11-20060816] Hollander、D.、Tobin、R.、Layman、A。、およびT. Bray、「XML 1.1の名前空間（第2版）」、World Wide Web Consortiumの推奨REC-XML-names11-20060816、2006年8月、<http://www.w3.org/tr/2006/rec-xml-names11-20060816>。
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802, February 2002.
[IEEE802] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ」、IEEE 802、2002年2月。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", March 1997, <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[EUI64] IEEE、「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、1997年3月<http://standards.ieee.org/regauth/oui/tutorials/ eui64.html>。
[E.164] ITU-T, "E.164 : The international public telecommunication numbering plan", ITU-T Recommendation E.164, February 2005, <http://www.itu.int/rec/T-REC-E.164-200502-I/en>.
[E.164] ITU-T、「E.164：国際公開通信番号計画」、ITU-T推奨E.164、2005年2月、<http://www.itu.int/rec/t-rec-E.164-200502-I/en>。
[E.213] ITU-T, "E.213 : Telephone and ISDN numbering plan for land mobile stations in public land mobile networks (PLMN)", ITU-T Recommendation E.213, November 1988, <http://www.itu.int/rec/T-REC-E.213-198811-I/en>.
[E.213] ITU-T、「E.213：公有地モバイルネットワーク（PLMN）の土地モバイルステーションの電話およびISDN番号付け計画」、ITU-T推奨E.213、1988年11月、<http：// www.itu.int/rec/t-rec-e.213-198811-i/en>。
[TS.3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 9.4.0, September 2010, <http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
[Ts.3GPP.23.003] 3GPP、「番号付け、アドレス指定、識別」、3GPP TS 23.003 9.4.0、2010年9月、<http://www.3gpp.org/ftp/specs/html-info/23003.htm>。
[TIA.EIA.IS-2000-6] TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread Spectrum Systems", TIA/EIA/IS-2000-6-C, May 2002.
[TIA.EIA.IS-2000-6] TIA/EIA、「CDMA 2000スプレッドスペクトルシステムのアナログシグナル伝達標準」、TIA/EIA/IS-2000-6-C、2002年5月。
[WiMAX-T33-110-R015v01-B] WiMAX Forum, "Protocols and Procedures for Location Based Services", WiMAX Forum Network Architecture T33-110- R015v01-B, May 2009.
[WIMAX-T33-110-R015V01-B] Wimax Forum、「ロケーションベースのサービスのプロトコルと手順」、Wimax Forum Network Architecture T33-110- R015V01-B、2009年5月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952] Kawamura、S。およびM. Kawashima、「IPv6アドレステキスト表現の推奨」、RFC 5952、2010年8月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101] Carpenter、B.、Crowcroft、J。、およびY. Rekhter、「IPv4アドレスToday」、RFC 2101、1997年2月。
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[RFC3825] Polk、J.、Schnizlein、J。、およびM. Linsner、「座標ベースの位置構成情報の動的ホスト構成プロトコルオプション」、RFC 3825、2004年7月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinne、H。、「電話番号のTel URI」、RFC 3966、2004年12月。
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[RFC4745] Schulzrinne、H.、Tschofenig、H.、Morris、J.、Cuellar、J.、Polk、J。、およびJ. Rosenberg、「共通政策：プライバシーの好みを表現するためのドキュメント形式」、RFC 4745、2月2007年。
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC4776] Schulzrinne、H。、「Dynamic Host Configuration Protocol（DHCPV4およびDHCPV6）CIVICアドレス構成情報のオプション」、RFC 4776、2006年11月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[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月。
[GEOPRIV-ARCH] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", Work in Progress, October 2010.
[Geopriv-Arch] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「インターネットアプリケーションの場所と場所のプライバシーのアーキテクチャ」、進捗、2010年10月。
[EMERGENCY-CALLING] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, October 2010.
[緊急コール] Rosen、B。およびJ. Polk、「緊急通話を支援するコミュニケーションサービスの最良の現在の実践」、2010年10月の作業。
Authors' Addresses
著者のアドレス
James Winterbottom Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
ジェームズウィンターボトムアンドリューコーポレーションアンドリュービルディング（39）ウォロンゴン大学キャンパスノースフィールズアベニューウロンゴン、NSW 2522 AU
Phone: +61 2 4221 2938
EMail: james.winterbottom@andrew.com
Martin Thomson Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
マーティントムソンアンドリューコーポレーションアンドリュービルディング（39）ウロンゴン大学キャンパスノースフィールズアベニューウロンゴン、NSW 2522 AU
Phone: +61 2 4221 2915
EMail: martin.thomson@andrew.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD 21046 USA
リチャードバーンズBBNテクノロジーズ9861壊れた土地PKWY、スイート400コロンビア、MD 21046 USA
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com