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)
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.
二つの追加のユースケースは、この文書によって対処されています。最初に、位置設定が要求に提供されたソースIPアドレスからの追加または代替の識別子を必要とします。第二に、デバイス以外のエンティティがデバイスの位置を要求します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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.
別に要求を形成するデータグラムから、位置情報サーバー（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は、追加の認証チェックせずにデバイスの身元を保証することができます。 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チェックが必要であり、かつ場合には、リクエスタ、デバイス自体でない場合には行うことができることを意味します。サードパーティの場所受信者（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.
この文書は、明示的にHELDロケーション要求の本体のデバイス識別情報を含めるための手段を規定します。この識別情報は、ロケーション要求の対象（又は対象）であるデバイスを識別するために使用されます。デバイスIDが存在する場合、送信元IPアドレスの形式で要求者の身元は、要求の対象を識別するために使用されていません。
Device identifiers in HELD can be used for two purposes:
HELDのデバイス識別子は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と一致する要求パケットにアドレス指定を改ざんした場合は、要求が誤ってこのポリシーの下で認可される可能性があります。具体的な措置がこの種の攻撃を防ぐために取られない限り、デバイスのアイデンティティを含む要求は、このポリシーを使用して許可してはなりません。
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）のために同じであることの保証を提供するメカニズムを説明しています。提供デバイスIDがリクエスタに一意に起因することを確認することができない限り、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]としてこの文書では、用語場所情報サーバー（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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要素は、デバイスのアイデンティティを表現するために使用されます。 「デバイス」要素は、識別情報のための一般的な容器として使用されます。この文書は、識別子の基本セットを定義します。図1に示す例HELD要求は、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>
<なLocationRequestのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：開催された" RESPONSETIME = "8"> <locationType正確= "真">測地</ locationType> <デバイスのxmlns = "URN：IETF：paramsは：XML ：NS：geopriv：保持：ID "> <IP V =" 4" > 192.0.2.5 </ IP> </デバイス> </な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は、位置決意するための基礎として使用された識別子を含む成功HELD応答して、「デバイス」要素をエコー。この指示の不在は、位置情報要求のソース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.
エラーコードを開催「badIdentifier」は、リクエスタがその識別子を使用することを許可または要求がひどくフォーマット又はLISによってサポートされていない識別子が含まれていることをされていないことを示しています。このコードは、セクション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は、要求で提供されていない識別子を必要とする場合、所望の識別子が「requiredIdentifiers」要素を使用して、HELDエラー応答して識別することができます。この要素は、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>
<エラーのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：開催された" コード= "badIdentifier"> <メッセージXML：LANG = "EN">必要なMACアドレス</メッセージ> <requiredIdentifiers用のxmlns = "URN：IETF ：のparams：XML：NS：geopriv：開催：ID "> MAC IP </ requiredIdentifiers> </エラー>
Figure 2: HELD Error Requesting Device Identifiers
図2：HELDエラー要求側デバイス識別子
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.
識別子の限られた選択は、本文書に含まれています。基本的なデバイス識別スキーマは、任意の名前空間からの要素の包含を可能にします。従って、追加の要素は、異なる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" 要素は、IPアドレス（[RFC0791]、[RFC4291]）などのデバイスのアイデンティティを表現することができます。 「V」属性は、16進数の1桁と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>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <IP V = "6"> 2001：DB8 :: 1：EA7：料金1：D1E </ IP> </デバイス>
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.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アドレスは、MAC-48、EUI-48、またはEUI64アドレス（[IEEE802]、または拡張一意識別子[EUI64]）[IEEE802]で定義された16進表現を使用して、として表すことができます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <mac>A0-12-34-56-78-90</mac> </device>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <MAC> A0-12-34-56-78-90 </ MAC> </デバイス>
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.
ホストは、それが送信または受信されたパケットのフローによって知られている可能性があります。それ自体で、ポート番号が一意に単一のホストを識別するには不十分です。 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>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <IPのV = "4"> 192.0.2.75 </ IP> <UDPPORT> 51393 </ UDPPORT> </デバイス>
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]はネットワークの範囲内でネットワーク認証に使用される識別子です。識別子は、特定のドメイン内のユーザのアイデンティティを確立します。多くの場合、ネットワークサービスは、ユーザーの認証と認可へのネットワークアクセスを結ぶ、場所レコードとの関係でNAIを使用します。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <nai>user@example.net</nai> </device>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <NAI> user@example.net </ NAI> </デバイス>
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つの大文字と小文字を区別しない16進数字が続くバックスラッシュ（「\」）を用いて発現させることができます。
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の正規表現は、エスケープ成分から誘導されるエスケープ文字とオクテットの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-ウムラウト文字（U + FC）を含み、無効なUTF-8オクテット（0xFFで）が示される可能性があり、例えば、NAI "F <U + FC> \ <0xFFの> @ bar.com" "\ 5C \ 90@bar.com BC F \ C3は\" として、U-ウムラウト文字が直接含まれている場合がありますけれども。
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-アイデンティティ・アサーション」パラメータを含んでいます。
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アドレスを保持ロケーション要求の送信元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
これは、[RFC5985]によって必要とされているIPアドレススプーフィングに対する同様の保護に依存しています。また、AAAからなる要求は、Diameter [RFC3588]またはRADIUS [RFC2865]のいずれかを使用し、したがってそれらのプロトコルによって提供される保護に依存しています。アクセス要求に依存しているために、AAAサーバは、間のリンクを提供する目的のために信頼できるエンティティであることを認証されなければなりません
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.
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]によって同定することができます。任意のURIは、要求者とLISは、URIの使用によって暗示さセマンティクスの共通の理解を持っていることを提供することができます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <uri>sip:user@example.net;gr=kjh29x97us97d</uri> </device>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <URI> SIP：user@example.net; GR = kjh29x97us97d </ URI> </デバイス>
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>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <URI>電話：800-555-1111;拡張= 1234;電話コンテキスト= + 1 </ URI> </デバイス>
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>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <FQDN> host.example.net </ FQDN> </デバイス>
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] E.164番号[E.164] 6〜15桁の長さです。
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：国際移動加入者識別（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）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）は、MSISDNと同様使用して、[E.164] E.164番号です。
Each identifier contains a string of decimal digits with a length as specified.
各識別子は、指定された長さの10進数の文字列が含まれています。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <msisdn>11235550123</msisdn> </device>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <MSISDN> 11235550123 </ MSISDN> </デバイス>
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）は[RFC3315]のセクション9で定義されたフォーマットのDHCPv4のオプション61（[RFC4361]を参照）、またはのDHCPv6のオプション1で発現させ、以下れます。 「DUID」要素は、DUIDのバイナリ値は16進数で表現含みます。
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <duid>1234567890AaBbCcDdEeFf</duid> </device>
<デバイスのxmlns = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID"> <DUID> 1234567890AaBbCcDdEeFf </ DUID> </デバイス>
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.
ベースHELDプロトコル[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.
ターゲットは、自身の位置を得るために、アイデンティティの拡張機能を使用する場合、もはやLCPと考えることができません開催されました。 LISは、これらの要求に応えるために使用する許可ポリシーは、一つ以上のルールメーカーによってプロビジョニングする必要があります。
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.
自分の位置とターゲットを提供するために、アイデンティティの拡張子で保持使用した場合に提供スプーフィング保護はLCPに固有の保護とは異なります。 LCPの場合は、リターン・ルータビリティは、スプーフィングに対する十分な保護を考えられています。同様のポリシーを使用するために、具体的な対策は、代替識別子のスプーフィングから保護するために定義されなければなりません。この文書は、WiMAXネットワークで使用された場合（セクション3.4.1を参照）NAIのためにこれを定義し、ない他の識別子のために。
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.
要求者とデバイスのアイデンティティとの間に直接的な1対1の関係が存在しない場合には注意が必要です。識別子が一意に単一のデバイスに帰属しない場合は、自分の場所で標的を提供するために保有アイデンティティエクステンションの使用は、攻撃者によって悪用される可能性があります。
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.
アイデンティティを含むすべてのHELD要求は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を含むリクエストの場合、要求者は認証[RFC2617]をダイジェストHTTPをサポートしなければなりません。デバイスIDを含む認証されていない位置要求は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.
HELD [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.
デバイスが提供するアイデンティティ情報は、機密であるかもしれないプライベートなデータです。デバイスは、デバイスのサービスを提供する際に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：スキーマのtargetNamespace = "URN：IETF：paramsは：XML：NS：geopriv：保持：ID" のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のxmlns：ID = "URN：IETF ：paramsは：XML：NS：geopriv：保持：ID」のelementFormDefault = " "修飾" attributeFormDefault =" 非修飾>
<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：注釈> <XS：APPINFOソース= "URN：IETF：paramsは：XML：スキーマ：geopriv：保持：ID">保持するデバイスアイデンティティ</ XS：APPINFO> <XS：ドキュメント・ソース= "HTTP：// WWW .rfc-editor.org / RFC / rfc6155.txt ">この文書を保持するためのデバイス識別要素を定義します。 </ XS：ドキュメンテーション> </ XS：注釈>
<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：要素名= "デバイス" タイプ= "ID：deviceIdentity" /> <XS：complexTypeの名= "deviceIdentity"> <XS：配列> <XS：任意の名前空間= "##いずれか" のprocessContents = "緩い" minOccurs属性= "0" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：complexTypeの>
<xs:element name="requiredIdentifiers" type="id:qnameList"/>
<XS：要素名= "requiredIdentifiers" タイプ= "ID：qnameList" />
<xs:simpleType name="qnameList"> <xs:list itemType="xs:QName"/> </xs:simpleType>
<XS：単純型名= "qnameList"> <XS：リストitemTypeに= "XS：QNameの" /> </ XS：単純>
<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：要素名= "IP" タイプ= "ID：ipAddressの" /> <XS：complexTypeの名前= "ipAddressの"> <XS：simpleContentを> <XS：増設ベース= "XS：トークン"> <XS：属性名= "V" 使用= "必要"> <XS：単純> <XS：制限ベース= "XS：トークン"> <XS：パターン値= "[DA-FA-F \]" /> </ XS：制限> </ XS：単純> </ XS：属性> </ XS：拡張> </ 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：要素名= "MAC" タイプ= "ID：MACADDRESS" /> <XS：単純型名= "MACADDRESS"> <XS：制限ベース= "XS：トークン"> <XS：パターン値= "[\ DA -fA-F] {2}（ - [\ DA-FA-F] {2}）{5}（（ - [\ DA-FA-F] {2}）{2}）？ "/> </ XS：制限> </ XS：単純>
<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：要素名= "UDPPORT" タイプ= "ID：ここで、portNumber" /> <XS：要素名= "TCPPORT" タイプ= "ID：ここで、portNumber" /> <XS：要素名= "sctpport" タイプ= "ID：ここで、portNumber "/> <XS：要素名=" dccpport」タイプ= "ID：ここで、portNumber" /> <XS：単純型名= "ここで、portNumber"> <XS：制限ベース= "XS：NonNegativeIntegerの"> <XS：maxInclusiveを値= "65535" /> </ XS：制限> </ XS：単純>
<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：要素名= "NAI" タイプ= "ID：naiType" /> <XS：単純型名= "naiType"> <XS：制限ベース= "XS：トークン"> <XS：パターン値= "（[^ \\] | \\ [\ 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 ：制限> </ XS：単純>
<xs:element name="uri" type="xs:anyURI"/>
<XS：要素名= "URI" タイプ= "XS：anyURIの" />
<xs:element name="fqdn" type="xs:token"/>
<XS：要素名= "FQDN" タイプ= "XS：トークン" />
<xs:element name="duid" type="xs:hexBinary"/>
<XS：要素名= "DUID" タイプ= "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：要素名= "MSISDN" タイプ= "ID：E164" /> <XS：要素名= "IMSI" タイプ= "ID：E164" /> <XS：要素名= "IMEI" タイプ= "ID： digit15 "/> <XS：要素名=" MIN」タイプ= "ID：digit10" /> <XS：要素名= "MDN" タイプ= "ID：E164" /> <XS：単純型名= "数字"> <XS：制限ベース= "XS：トークン"> <XS：パターン値= "[\ D] +" /> </ XS：制限> </ XS：単純> <XS：単純型名= "E164"> < XS：制限ベース= "ID：digit15"> <XS：はminLength値= "6" /> </ XS：制限> </ XS：単純> <XS：単純型名= "digit15"> <XS：制限塩基= "ID：数字"> <XS：maxLengthの値= "15" /> </ XS：制限> </ XS：単純> <XS：単純型名= "digit10"> <XS：制限ベース= "ID：数字" > <XS：長さ値= "10" /> </ XS：制限> </ XS：simpleTypeの>
</xs:schema>
</ XS：スキーマ>
This document registers an XML namespace and schema with IANA in accordance with guidelines in [RFC3688].
この文書では、[RFC3688]のガイドラインに従い、IANAでXML名前空間とスキーマを登録します。
7.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:id
7.1. 骨壷のためのURNサブ名前空間の登録：IETF：のparams：XML：NS：geopriv：開催：ID
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in [RFC3688].
[RFC3688]のガイドラインに従って、 "ID：IETF：のparams：XML：NS：geopriv：開催壷" このセクションでは、新しいXML名前空間を、登録します。
URI: urn:ietf:params:xml:ns:geopriv:held:id
URI：URN：IETF：paramsは：XML：NS：geopriv：保持：ID
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).
登録者連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、ジェームズ・ウィンターボトム（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
BEGINの<？xml version = "1.0"？> <！DOCTYPE htmlのをPUBLIC！ " - // W3C // DTD XHTML 1.0厳格// EN"「http://www.w3.org/TR/xhtml1/DTD/xhtml1- strict.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml」XML：LANG = "EN"> <HEAD> <TITLE>携帯デバイスアイデンティティパラメータ</ TITLE> </ HEAD> <身体> <H1>携帯デバイスアイデンティティパラメータの名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：geopriv：開催：ID </ H2> <P>を参照してください。<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
URI：URN：IETF：paramsは：XML：スキーマは：geopriv：保持：ID
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), James Winterbottom (james.winterbottom@andrew.com).
登録者連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、ジェームズ・ウィンターボトム（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に「悪い識別子」エラーコードを登録する「GプライベートHTTP有効ロケーション配信（保持）パラメータ」レジストリの「HELDエラーコード」サブレジストリを維持しました。
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.
badIdentifierこのエラーコードは、いずれかHELD要求に使用されるデバイス識別子があったことを示す：リクエスタが要求を行うことを許可されたための一ひどくフォーマット、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
全国緊急番号協会（NENA）のVoIP場所ワーキンググループは、このドキュメントで使用されるスキーマの定義で支援を提供しました。特別な感謝はバーバラ・スターク、ガイに行きます
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.
キャロン、ナディーヌ・アボット、ジェロームグルニエ、そしてマーティン・ドーソン。ボブ・シェリーは、URIの使用に入力を提供します。さらに修正を提供するためのアダムMuhlbauerとエディーコルベットに感謝します。バーナードAbobaは、ユースケースとセキュリティモデルに優れたフィードバックを提供します。バーナードは、アランDeKokとともに、またのNAIとの問題を解決する助けました。レイ・ベリスは、プロトコル、ポートのパラメータのモチベーションを提供しました。マルクLinsnerとアリッサクーパー大幅のLCPに関する議論を明確にそのガイダンスと（それぞれ）のテキストを提供しました。実用的ではこれを強制ためのジョン・ピーターソンとカレンジェニングスに感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（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]レモン、T.とB.ゾンマーフェルト、RFC 4361、2006年2月「動的ホスト構成プロトコルバージョン四つ（のDHCPv4）のためのノード固有のクライアント識別子」。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J.、 "アプリケーション（IDNA）のための国際化ドメイン名：定義とドキュメントフレームワーク"、RFC 5890、2010年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]バーンズ、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]オランダ、D.、トービン、R.、素人、A.、およびT.ブレイ、 "XML 1.1の名前空間（第二版）"、ワールドワイドウェブコンソーシアム勧告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ビットのグローバル識別子（EUI64）登録機関のためのガイドライン"、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：電話とISDN公衆陸上モバイルネットワーク（PLMN）で陸上移動局用の番号計画"、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フォーラム、 "位置情報サービスのためのプロトコルと手順"、WiMAXフォーラムネットワークアーキテクチャT33-110- R015v01-B、2009年05月05日。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]川村、S.とM.川島、RFC 5952、2010年8月、 "IPv6アドレスのテキスト表現のための勧告"。
[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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101]カーペンター、B.、クロウクロフト、J.、およびY. Rekhter、 "IPv4アドレス動作今日"、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]ポーク、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.、モリス、J.、クエリャル、J.、ポーク、J.、およびJ.ローゼンバーグ、 "共通ポリシー：プライバシー設定を表現するためのドキュメントフォーマット"、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.、RFC 4776、2006年11月 "シビック用動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションは、構成情報をアドレス"。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]ローゼンバーグ、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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レイヤ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]バーンズ、R.、Lepinski、M.、クーパー、A.、モリス、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.
[EMERGENCY-CALLING]ローゼン、B.とJ.ポーク、「緊急コールのサポートにおける通信サービスのための最も良い現在の練習」、進歩、2010年10月の作業。
Authors' Addresses
著者のアドレス
James Winterbottom Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
ジェームズ・ウィンターボトムアンドリュー・コーポレーションアンドリュービル（39）ウーロンゴン大学キャンパスNorthfieldsアベニューウロンゴン、NSW 2522 AU
Phone: +61 2 4221 2938 EMail: james.winterbottom@andrew.com
電話：+61 2 4221 2938 Eメール：james.winterbottom@andrew.com
Martin Thomson Andrew Corporation Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
マーティン・トムソンアンドリュー・コーポレーションアンドリュービル（39）ウーロンゴン大学キャンパスNorthfieldsアベニューウロンゴン、NSW 2522 AU
Phone: +61 2 4221 2915 EMail: martin.thomson@andrew.com
電話：+61 2 4221 2915 Eメール：martin.thomson@andrew.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：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ブロークン・ランドパークウェイ、スイート400コロンビア、MD 21046 USA
Phone: +1 410 290 6169 EMail: rbarnes@bbn.com
電話：+1 410 290 6169 Eメール：rbarnes@bbn.com