[要約] RFC 6772は、位置情報のプライバシー設定を表現するためのドキュメント形式に関するものであり、位置情報の利用に関するプライバシー設定を標準化することを目的としています。
Internet Engineering Task Force (IETF) H. Schulzrinne, Ed.
Request for Comments: 6772 Columbia University
Category: Standards Track H. Tschofenig, Ed.
ISSN: 2070-1721 Nokia Siemens Networks
J. Cuellar
Siemens
J. Polk
Cisco
J. Morris
M. Thomson Microsoft January 2013
M.トムソンマイクロソフト2013年1月
Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information
地理位置情報ポリシー：位置情報のプライバシー設定を表現するためのドキュメント形式
Abstract
概要
This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.
このドキュメントでは、位置情報へのアクセスを制御するための承認ポリシー言語を定義しています。 Common Policy許可フレームワークを拡張して、ロケーション固有のアクセス制御を提供します。具体的には、このドキュメントでは、ターゲットの現在の場所に基づいてデータへのアクセスを制限するために、場所情報に固有の条件要素を定義しています。
Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains.
さらに、このドキュメントでは、返される位置情報の粒度を減らすための2つのアルゴリズムを定義しています。最初のアルゴリズムは、都市の位置情報を使用するために定義されていますが、他のアルゴリズムは測地位置情報に適用されます。どちらのアルゴリズムにも制限があります。提供される場所の難読化の量が望ましいものより少ない状況があります。これらのアルゴリズムは、すべてのアプリケーションドメインに適しているとは限りません。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6772.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6772で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Structure of Geolocation Authorization Documents . . . . . 7
3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 7
4. Location-Specific Conditions . . . . . . . . . . . . . . . . . 7
4.1. Geodetic Location Condition Profile . . . . . . . . . . . 8
4.2. Civic Location Condition Profile . . . . . . . . . . . . . 9
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 9
6.2. Set Retention-Expiry . . . . . . . . . . . . . . . . . . . 10
6.3. Set Note-Well . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 10
6.5. Provide Location . . . . . . . . . . . . . . . . . . . . . 11
6.5.1. Civic Location Profile . . . . . . . . . . . . . . . . 12
6.5.2. Geodetic Location Profile . . . . . . . . . . . . . . 13
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Rule Example with Civic Location Condition . . . . . . . . 15
7.2. Rule Example with Geodetic Location Condition . . . . . . 16
7.3. Rule Example with Civic and Geodetic Location Condition . 17
7.4. Rule Example with Location-Based Transformations . . . . . 18
7.5. Location Obfuscation Example . . . . . . . . . . . . . . . 19
8. XML Schema for Basic Location Profiles . . . . . . . . . . . . 23
9. XML Schema for Geolocation Policy . . . . . . . . . . . . . . 24
10. XCAP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Application Unique ID . . . . . . . . . . . . . . . . . . 26
10.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 26
10.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 26
10.4. MIME Media Type . . . . . . . . . . . . . . . . . . . . . 26
10.5. Validation Constraints . . . . . . . . . . . . . . . . . . 26
10.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 26
10.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 26
10.8. Resource Interdependencies . . . . . . . . . . . . . . . . 26
10.9. Authorization Policies . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11.1. Geolocation Policy XML Schema Registration . . . . . . . . 27
11.2. Geolocation Policy Namespace Registration . . . . . . . . 27
11.3. Geolocation Policy Location Profile Registry . . . . . . . 28
11.4. Basic Location Profile XML Schema Registration . . . . . . 28
11.5. Basic Location Profile Namespace Registration . . . . . . 29
11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 29
12. Internationalization Considerations . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 30
13.2. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 31
13.3. Algorithm Limitations . . . . . . . . . . . . . . . . . . 32
13.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . 33
13.5. Limitations of Obscuring Locations . . . . . . . . . . . . 33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 38
Appendix B. Pseudocode . . . . . . . . . . . . . . . . . . . . . 39
Location information needs to be protected against unauthorized access to preserve the privacy of humans. In RFC 6280 [RFC6280], a protocol-independent model for access to geographic information is defined. The model includes a Location Generator (LG) that determines location information, a Location Server (LS) that authorizes access to location information, a Location Recipient (LR) that requests and receives location information, and a Rule Maker (RM) that writes authorization policies. An authorization policy is a set of rules that regulates an entity's activities with respect to privacy-sensitive information, such as location information.
人間のプライバシーを保護するために、位置情報を不正アクセスから保護する必要があります。 RFC 6280 [RFC6280]では、地理情報にアクセスするためのプロトコルに依存しないモデルが定義されています。モデルには、位置情報を決定するLocation Generator（LG）、位置情報へのアクセスを許可するLocation Server（LS）、位置情報を要求および受信するLocation Recipient（LR）、および許可を書き込むRule Maker（RM）が含まれますポリシー。承認ポリシーは、位置情報などのプライバシーに配慮した情報に関するエンティティのアクティビティを規制する一連のルールです。
The data object containing location information in the context of this document is referred to as a Location Object (LO). The basic rule set defined in the Presence Information Data Format Location Object (PIDF-LO) [RFC4119] can restrict how long the Location Recipient is allowed to retain the information, and it can prohibit further distribution. It also contains a reference to an enhanced rule set and a human-readable privacy policy. The basic rule set does not protect access to location information. It only conveys the user's privacy preferences. This document describes an enhanced rule set that provides richer constraints on the distribution of LOs.
このドキュメントのコンテキストで位置情報を含むデータオブジェクトは、位置オブジェクト（LO）と呼ばれます。プレゼンス情報データフォーマットロケーションオブジェクト（PIDF-LO）[RFC4119]で定義された基本ルールセットは、ロケーション受信者が情報を保持できる時間を制限し、それ以上の配布を禁止できます。また、拡張されたルールセットと人間が読めるプライバシーポリシーへの参照も含まれています。基本ルールセットは、位置情報へのアクセスを保護しません。ユーザーのプライバシー設定のみを伝えます。このドキュメントでは、LOの分布に対してより豊富な制約を提供する拡張ルールセットについて説明します。
The enhanced rule set allows the entity that uses the rules defined in this document to restrict the retention and to enforce access restrictions on location data, including prohibiting any dissemination to particular individuals, during particular times or when the Target is located in a specific region. The RM can also stipulate that only certain parts of the Location Object are to be distributed to recipients or that the resolution is reduced for parts of the Location Object.
拡張されたルールセットにより、このドキュメントで定義されたルールを使用するエンティティは、保持を制限し、特定の時間帯またはターゲットが特定の地域にあるときに、特定の個人への配布を禁止するなど、位置データにアクセス制限を適用できます。 RMは、ロケーションオブジェクトの特定の部分のみが受信者に配布されること、またはロケーションオブジェクトの一部の解像度が低下することを規定することもできます。
In the typical sequence of operations, a Location Server receives a query for location information for a particular Target. The authenticated identity of the Location Recipient, together with other information provided with the request or generally available to the server, is then used for searching through the rule set. If more than one rule matches the condition element, then the combined permission is evaluated according to the description in Section 10 of [RFC4745]. The result of the rule evaluation is applied to the location information, yielding a possibly modified Location Object that is delivered to the Location Recipient.
通常の操作シーケンスでは、ロケーションサーバーが特定のターゲットのロケーション情報のクエリを受け取ります。ロケーション受信者の認証済みIDは、リクエストで提供された、またはサーバーで一般に利用可能な他の情報と一緒に、ルールセットの検索に使用されます。複数のルールが条件要素に一致する場合、組み合わされた権限は、[RFC4745]のセクション10の説明に従って評価されます。ルール評価の結果がロケーション情報に適用され、ロケーション受信者に配信される可能性のある変更されたロケーションオブジェクトが生成されます。
This document does not describe the protocol used to convey location information from the Location Server to the Location Recipient.
このドキュメントでは、ロケーションサーバからロケーション受信者にロケーション情報を伝達するために使用されるプロトコルについては説明していません。
This document extends the Common Policy framework defined in [RFC4745]. That document provides an abstract framework for expressing authorization rules. As specified there, each such rule consists of conditions, actions, and transformations. Conditions determine under which circumstances the entity executing the rules, such as a Location Server, is permitted to apply actions and transformations. In a location information context, transformations regulate how a Location Server modifies the information elements that are returned to the requestor by, for example, reducing the granularity of returned location information.
このドキュメントは、[RFC4745]で定義されているCommon Policyフレームワークを拡張します。そのドキュメントは、認可ルールを表現するための抽象的なフレームワークを提供します。そこで指定されているように、そのような各ルールは条件、アクション、および変換で構成されています。条件は、ロケーションサーバーなど、ルールを実行するエンティティがアクションと変換を適用できる状況を決定します。ロケーション情報のコンテキストでは、トランスフォーメーションは、たとえば、返されるロケーション情報の粒度を減らすことにより、ロケーションサーバーがリクエスタに返される情報要素を変更する方法を制御します。
This document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information (see Section 6.5.1) while the other one applies to geodetic location information (see Section 6.5.2). Both algorithms come with limitations, i.e., they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. These limitations are documented within the Security Consideration section (see Section 13). The geodetic transformation algorithm in Section 6.5.2 mitigates privacy risks for both stationary and moving Targets. However, moving Targets will reveal additional information to an adversary. To cover applications that have more sophisticated privacy requirements, additional algorithms may need to be defined. This document foresees extensions in the form of new algorithms and therefore defines a registry (see Section 11.3).
このドキュメントでは、返される位置情報の粒度を減らすための2つのアルゴリズムを定義しています。最初のアルゴリズムは、都市の位置情報（セクション6.5.1を参照）での使用のために定義されていますが、他のアルゴリズムは測地位置情報（セクション6.5.2を参照）に適用されます。どちらのアルゴリズムにも制限があります。つまり、特定の条件下で位置の難読化が行われるため、すべてのアプリケーションドメインに適しているとは限りません。これらの制限は、セキュリティに関する考慮事項のセクションに記載されています（セクション13を参照）。セクション6.5.2の測地変換アルゴリズムは、静止ターゲットと移動ターゲットの両方のプライバシーリスクを軽減します。ただし、ターゲットを移動すると、敵に追加情報が表示されます。より高度なプライバシー要件を持つアプリケーションをカバーするには、追加のアルゴリズムを定義する必要がある場合があります。このドキュメントでは、新しいアルゴリズムの形式で拡張を予測しているため、レジストリを定義しています（セクション11.3を参照）。
The XML schema defined in Section 9 extends the Common Policy schema by introducing new child elements to the condition and transformation elements. This document does not define child elements for the action part of a rule.
セクション9で定義されたXMLスキーマは、条件と変換要素に新しい子要素を導入することにより、共通ポリシースキーマを拡張します。このドキュメントでは、ルールのアクション部分の子要素を定義していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document reuses the terminology of RFC 6280 [RFC6280], such as Location Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Location Generator (LG), and Location Object (LO). This document uses the following terminology:
このドキュメントでは、ロケーションサーバー（LS）、ロケーション受信者（LR）、ルールメーカー（RM）、ターゲット、ロケーションジェネレーター（LG）、ロケーションオブジェクト（LO）などのRFC 6280 [RFC6280]の用語を再利用します。このドキュメントでは、次の用語を使用しています。
Presentity or Target:
プレゼンティティまたはターゲット：
RFC 6280 [RFC6280] uses the term "Target" to identify the object or person of which location information is required. The presence model described in RFC 2778 [RFC2778] uses the term "presentity" to describe the entity that provides presence information to a presence service. A presentity in a presence system is a Target in a location information system.
RFC 6280 [RFC6280]は、「ターゲット」という用語を使用して、位置情報が必要なオブジェクトまたは人物を識別します。 RFC 2778 [RFC2778]で説明されているプレゼンスモデルでは、「プレゼンティティ」という用語を使用して、プレゼンスサービスにプレゼンス情報を提供するエンティティを説明しています。プレゼンスシステムのプレゼンティティは、位置情報システムのターゲットです。
Watcher or Location Recipient:
ウォッチャーまたは場所の受信者：
The receiver of location information is the Location Recipient (LR) in the terminology of RFC 6280 [RFC6280]. A watcher in a presence system, i.e., an entity that requests presence information about a presentity, is a Location Recipient in a location information system.
ロケーション情報の受信者は、RFC 6280 [RFC6280]の用語では、ロケーション受信者（LR）です。プレゼンスシステムのウォッチャー、つまりプレゼンティティに関するプレゼンス情報を要求するエンティティは、ロケーション情報システムのロケーション受信者です。
Authorization policy:
承認ポリシー：
An authorization policy is given by a rule set. A rule set contains an unordered list of (policy) rules. Each rule has a condition, an action, and a transformation component.
承認ポリシーは、ルールセットによって提供されます。ルールセットには、（ポリシー）ルールの順不同リストが含まれています。各ルールには、条件、アクション、および変換コンポーネントがあります。
Permission:
許可：
The term "permission" refers to the action and transformation components of a rule.
「許可」という用語は、ルールのアクションおよび変換コンポーネントを指します。
Location Servers:
ロケーションサーバー：
Entities that evaluate the geolocation authorization policies.
地理位置情報承認ポリシーを評価するエンティティ。
Presence Servers:
プレゼンスサーバー：
The geolocation privacy architecture is, as described in RFC 4079 [RFC4079], aligned with the presence architecture, and a "Presence Server" is therefore an entity that distributes location information along with other presence-specific XML data elements.
地理位置情報プライバシーアーキテクチャは、RFC 4079 [RFC4079]で説明されているように、プレゼンスアーキテクチャと整合しているため、「プレゼンスサーバー」は、他のプレゼンス固有のXMLデータ要素と共に位置情報を配信するエンティティです。
A geolocation authorization document is an XML document, formatted according to the schema defined in [RFC4745]. Geolocation authorization documents inherit the media type of Common Policy documents, application/auth-policy+xml. As described in [RFC4745], this document is composed of rules that contain three parts: conditions, actions, and transformations. Each action or transformation, which is also called a permission, has the property of being a positive grant of information to the Location Recipient. As a result, there is a well-defined mechanism for combining actions and transformations obtained from several sources. This mechanism is privacy enabling, since the lack of any action or transformation can only result in less information being presented to a Location Recipient.
地理位置情報承認ドキュメントは、[RFC4745]で定義されているスキーマに従ってフォーマットされたXMLドキュメントです。地理位置情報承認ドキュメントは、共通ポリシードキュメントのメディアタイプapplication / auth-policy + xmlを継承します。 [RFC4745]で説明されているように、このドキュメントは、条件、アクション、変換の3つの部分を含むルールで構成されています。許可とも呼ばれる各アクションまたは変換には、ロケーション受信者への積極的な情報の付与という特性があります。その結果、いくつかのソースから取得したアクションと変換を組み合わせるための明確に定義されたメカニズムがあります。アクションや変換を行わないと、ロケーション受信者に提供される情報が少なくなるため、このメカニズムはプライバシーを有効にします。
There are two ways the authorization rules described in this document may be conveyed between different parties:
このドキュメントで説明されている承認規則を異なる当事者間で伝達する方法は2つあります。
o RFC 4119 [RFC4119] allows enhanced authorization policies to be referenced via a Uniform Resource Locator (URL) in the 'ruleset-reference' element. The 'ruleset-reference' element is part of the basic rules that always travel with the Location Object.
o RFC 4119 [RFC4119]では、拡張された承認ポリシーを「ruleset-reference」要素のUniform Resource Locator（URL）経由で参照できます。 「ruleset-reference」要素は、常にLocationオブジェクトとともに移動する基本的なルールの一部です。
o Authorization policies might, for example, also be stored at a Location Server / Presence Server. The Rule Maker therefore needs to use a protocol to create, modify, and delete the authorization policies defined in this document. Such a protocol is available with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825].
o 許可ポリシーは、たとえば、ロケーションサーバー/プレゼンスサーバーにも保存されます。したがって、ルールメーカーは、プロトコルを使用して、このドキュメントで定義されている承認ポリシーを作成、変更、および削除する必要があります。このようなプロトコルは、Extensible Markup Language（XML）構成アクセスプロトコル（XCAP）[RFC4825]で利用できます。
This section describes the location-specific conditions of a rule. The <conditions> element contains zero or more <location-condition> child element(s). The <conditions> element only evaluates to TRUE if all child elements evaluate to TRUE; therefore, multiple <location-condition> elements are not normally useful.
このセクションでは、ルールの場所固有の条件について説明します。 <conditions>要素には、ゼロ個以上の<location-condition>子要素が含まれています。 <conditions>要素は、すべての子要素がTRUEと評価された場合にのみTRUEと評価されます。したがって、複数の<location-condition>要素は通常は役に立ちません。
The <location-condition> element MUST contain at least one <location> child element. The <location-condition> element evaluates to TRUE if any of its child <location> elements matches the location of the Target, i.e., <location> elements are combined using a logical OR.
<location-condition>要素には、少なくとも1つの<location>子要素が含まれている必要があります。 <location-condition>要素は、その子<location>要素のいずれかがターゲットの場所と一致する場合、つまり、<location>要素が論理ORを使用して結合される場合、TRUEと評価されます。
The three attributes of <location> are 'profile', 'xml:lang', and 'label'. The 'profile' indicates the location profile that is included as child elements in the <location> element. Two location profiles, geodetic and civic, are defined in Sections 4.1 and 4.2. Each profile describes under what conditions a <location> element evaluates to TRUE.
<location>の3つの属性は、「profile」、「xml：lang」、および「label」です。 「プロファイル」は、<location>要素の子要素として含まれる場所のプロファイルを示します。測地および市民の2つの位置プロファイルは、セクション4.1および4.2で定義されています。各プロファイルは、<location>要素がどの条件でTRUEと評価されるかを示します。
The 'label' attribute allows a human-readable description to be added to each <location> element. The 'xml:lang' attribute contains a language tag providing further information for rendering of the content of the 'label' attribute.
'label'属性を使用すると、人間が読める説明を各<location>要素に追加できます。 「xml：lang」属性には、「label」属性のコンテンツのレンダリングに関する詳細情報を提供する言語タグが含まれています。
The <location-condition> and the <location> elements provide extension points. If an extension is not understood by the entity evaluating the rules, then this rule evaluates to FALSE. This causes a <conditions> element to evaluate to FALSE if a <location-condition> element is unsupported. A <location-condition> is considered TRUE if any of the <location> elements understood by the rule evaluator is TRUE.
<location-condition>および<location>要素は、拡張ポイントを提供します。ルールを評価するエンティティが拡張機能を理解できない場合、このルールはFALSEと評価されます。これにより、<location-condition>要素がサポートされていない場合、<conditions>要素はFALSEと評価されます。ルールエバリュエーターが理解できる<location>要素のいずれかがTRUEの場合、<location-condition>はTRUEと見なされます。
The geodetic location profile is identified by the token 'geodetic-condition'. Rule Makers use this profile by placing a Geography Markup Language [GML] <Circle> element within the <location> element (as described in Section 5.2.3 of [RFC5491]).
測地位置プロファイルは、トークン「geodetic-condition」によって識別されます。ルールメーカーはこのプロファイルを使用して、Geography Markup Language [GML] <Circle>要素を<location>要素内に配置します（[RFC5491]のセクション5.2.3で説明）。
The <location> element containing the information for the geodetic location profile evaluates to TRUE if the current location of the Target is completely within the described location (see Section 6.1.15.3 of [OGC-06-103r4]). Note that the Target's actual location might be represented by any of the location shapes described in [RFC5491]. If the geodetic location of the Target is unknown, then the <location> element containing the information for the geodetic location profile evaluates to FALSE.
測地位置プロファイルの情報を含む<location>要素は、ターゲットの現在の位置が記述された位置内に完全にある場合にTRUEと評価されます（[OGC-06-103r4]のセクション6.1.15.3を参照）。ターゲットの実際の場所は、[RFC5491]で説明されている場所の形状のいずれかで表される場合があることに注意してください。ターゲットの測地位置が不明な場合、測地位置プロファイルの情報を含む<location>要素はFALSEと評価されます。
Implementations MUST support the World Geodetic System 1984 (WGS 84) [NIMA.TR8350.2-3e] coordinate reference system using the formal identifier from the European Petroleum Survey Group (EPSG) Geodetic Parameter Dataset (as formalized by the Open Geospatial Consortium (OGC)):
実装では、World Geodetic System 1984（WGS 84）[NIMA.TR8350.2-3e]座標参照システムをサポートする必要があります。 ））：
2D: WGS 84 (latitude, longitude), as identified by the URN "urn:ogc:def:crs:EPSG::4326". This is a two-dimensional CRS.
2D：UGS「urn：ogc：def：crs：EPSG :: 4326」で識別されるWGS 84（緯度、経度）。これは2次元のCRSです。
A Coordinate Reference System (CRS) MUST be specified using the above URN notation only; implementations do not need to support user-defined CRSs.
座標参照システム（CRS）は、上記のURN表記のみを使用して指定する必要があります。実装では、ユーザー定義のCRSをサポートする必要はありません。
Implementations MUST specify the CRS using the "srsName" attribute on the outermost geometry element. The CRS MUST NOT be changed for any sub-elements. The "srsDimension" attribute MUST be omitted, since the number of dimensions in these CRSs is known.
実装では、最も外側のジオメトリ要素の「srsName」属性を使用してCRSを指定する必要があります。サブエレメントのCRSを変更してはなりません。これらのCRSの次元数は既知であるため、「srsDimension」属性は省略しなければなりません。
The civic location profile is identified by the token 'civic-condition'. Rule Makers use this profile by placing a <civicAddress> element, defined in [RFC5139], within the <location> element.
都市ロケーションプロファイルは、「civic-condition」というトークンで識別されます。ルールメーカーは、<location>要素内に[RFC5139]で定義された<civicAddress>要素を配置することにより、このプロファイルを使用します。
All child elements of a <location> element that carry <civicAddress> elements MUST evaluate to TRUE (i.e., logical AND) in order for the <location> element to evaluate to TRUE. For each child element, the value of that element is compared to the value of the same element in the Target's civic location. The child element evaluates to TRUE if the two values are identical based on an octet-by-octet comparison.
<location>要素がTRUEと評価されるためには、<civicAddress>要素を持つ<location>要素のすべての子要素がTRUE（つまり、論理AND）と評価される必要があります。各子要素について、その要素の値は、ターゲットの都市の場所にある同じ要素の値と比較されます。 2つの値がオクテットごとの比較に基づいて同一である場合、子要素はTRUEと評価されます。
A <location> element containing a <civic-condition> profile evaluates to FALSE if a civic address is not present for the Target. For example, this could occur if location information has been removed by other rules or other transmitters of location information or if only the geodetic location is known. In general, it is RECOMMENDED behavior for an LS not to apply a translation from geodetic location to civic location (i.e., geocode the location).
<civic-condition>プロファイルを含む<location>要素は、ターゲットに都市の住所が存在しない場合、FALSEと評価されます。たとえば、位置情報が他のルールまたは他の位置情報の送信者によって削除された場合、または測地位置のみがわかっている場合に、これが発生する可能性があります。一般に、測地位置から都市の位置への変換を適用しないこと（つまり、位置をジオコーディングすること）は、LSにとって推奨される動作です。
This document does not define location-specific actions.
このドキュメントでは、場所固有のアクションを定義していません。
This document defines several elements that allow Rule Makers to specify transformations that
このドキュメントでは、ルールメーカーが変換を指定できるようにするいくつかの要素を定義します
o reduce the accuracy of the returned location information, and
o 返される位置情報の精度を低下させる
o set the basic authorization policies carried inside the PIDF-LO.
o PIDF-LO内で実行される基本的な許可ポリシーを設定します。
This element specifies a change to or the creation of a value for the <retransmission-allowed> element in the PIDF-LO. The data type of the <set-retransmission-allowed> element is a boolean.
この要素は、PIDF-LOの<retransmission-allowed>要素の値の変更または作成を指定します。 <set-retransmission-allowed>要素のデータ型はブール値です。
If the value of the <set-retransmission-allowed> element is set to TRUE, then the <retransmission-allowed> element in the PIDF-LO MUST be set to TRUE. If the value of the <set-retransmission-allowed> element is set to FALSE, then the <retransmission-allowed> element in the PIDF-LO MUST be set to FALSE.
<set-retransmission-allowed>要素の値がTRUEに設定されている場合、PIDF-LOの<retransmission-allowed>要素はTRUEに設定する必要があります。 <set-retransmission-allowed>要素の値がFALSEに設定されている場合、PIDF-LOの<retransmission-allowed>要素はFALSEに設定する必要があります。
If the <set-retransmission-allowed> element is absent, then the value of the <retransmission-allowed> element in the PIDF-LO MUST be kept unchanged, or if the PIDF-LO is created for the first time, then the value MUST be set to FALSE.
<set-retransmission-allowed>要素がない場合は、PIDF-LOの<retransmission-allowed>要素の値を変更しないでおく必要があります。または、PIDF-LOを初めて作成する場合は、値FALSEに設定する必要があります。
This transformation asks the LS to change or set the value of the <retention-expiry> element in the PIDF-LO. The data type of the <set-retention-expiry> element is a non-negative integer.
この変換は、LSにPIDF-LOの<retention-expiry>要素の値を変更または設定するように要求します。 <set-retention-expiry>要素のデータ型は、負でない整数です。
The value provided with the <set-retention-expiry> element indicates seconds, and these seconds are added to the time that the LS provides location. A value of zero requests that the information is not retained.
<set-retention-expiry>要素で提供される値は秒を示し、LSが場所を提供する時間にこれらの秒が追加されます。ゼロの値は、情報が保持されないことを要求します。
If the <set-retention-expiry> element is absent, then the value of the <retention-expiry> element in the PIDF-LO is kept unchanged, or if the PIDF-LO is created for the first time, then the value MUST be set to the current date.
<set-retention-expiry>要素が存在しない場合、PIDF-LOの<retention-expiry>要素の値は変更されずに維持されるか、またはPIDF-LOが初めて作成される場合、値は現在の日付に設定されます。
This transformation asks the LS to change or set the value of the <note-well> element in the PIDF-LO. The data type of the <set-note-well> element is a string.
この変換は、LSにPIDF-LOの<note-well>要素の値を変更または設定するように要求します。 <set-note-well>要素のデータ型は文字列です。
The value provided with the <set-note-well> element contains a privacy statement as a human-readable text string, and an 'xml:lang' attribute denotes the language of the human-readable text.
<set-note-well>要素で提供される値には、人間が読めるテキスト文字列としてプライバシーに関する声明が含まれ、「xml：lang」属性は人間が読めるテキストの言語を示します。
If the <set-note-well> element is absent, then the value of the <note-well> element in the PIDF-LO is kept unchanged, or if the PIDF-LO is created for the first time, then no content is provided for the <note-well> element.
<set-note-well>要素が存在しない場合、PIDF-LOの<note-well>要素の値は変更されずに維持されるか、またはPIDF-LOが初めて作成される場合、コンテンツはありません。 <note-well>要素に提供されます。
This transformation specifies whether the <external-ruleset> element in the PIDF-LO carries the extended authorization rules defined in [RFC4745]. The data type of the <keep-rule-reference> element is boolean.
この変換は、PIDF-LOの<external-ruleset>要素が[RFC4745]で定義されている拡張承認ルールを運ぶかどうかを指定します。 <keep-rule-reference>要素のデータ型はブール型です。
If the value of the <keep-rule-reference> element is set to TRUE, then the <external-ruleset> element in the PIDF-LO is kept unchanged when included. If the value of the <keep-rule-reference> element is set to FALSE, then the <external-ruleset> element in the PIDF-LO MUST NOT contain a reference to an external rule set. The reference to the ruleset is removed, and no rules are carried as MIME bodies (in case of Content-ID (cid:) URIs [RFC2392]).
<keep-rule-reference>要素の値がTRUEに設定されている場合、PIDF-LOの<external-ruleset>要素は、含まれている場合は変更されません。 <keep-rule-reference>要素の値がFALSEに設定されている場合、PIDF-LOの<external-ruleset>要素に外部ルールセットへの参照を含めることはできません。ルールセットへの参照は削除され、ルールはMIME本文として伝達されません（Content-ID（cid :) URI [RFC2392]の場合）。
If the <keep-rule-reference> element is absent, then the value of the <external-ruleset> element in the PIDF-LO is kept unchanged when available, or if the PIDF-LO is created for the first time, then the <external-ruleset> element MUST NOT be included.
<keep-rule-reference>要素が存在しない場合、PIDF-LOの<external-ruleset>要素の値は、利用可能な場合は変更されずに維持されるか、またはPIDF-LOが初めて作成された場合、 <external-ruleset>要素を含めることはできません。
The <provide-location> element contains child elements of a specific location profile that controls the granularity of returned location information. This form of location granularity reduction is also called 'obfuscation' and is defined in [DUCKHAM05] as
<provide-location>要素には、返される場所情報の粒度を制御する特定の場所プロファイルの子要素が含まれます。この場所の粒度の削減の形式は「難読化」とも呼ばれ、[DUCKHAM05]で次のように定義されています。
the means of deliberately degrading the quality of information about an individual's location in order to protect that individual's location privacy.
個人の場所のプライバシーを保護するために、個人の場所に関する情報の品質を意図的に低下させる手段。
Location obscuring presents a number of technical challenges. The algorithms provided in this document are provided as examples only. A discussion of the technical constraints on location obscuring is included in Section 13.5.
ロケーションが不明瞭になると、いくつかの技術的な課題が生じます。このドキュメントで提供されているアルゴリズムは、例としてのみ提供されています。場所の不明瞭化に関する技術的な制約の説明は、セクション13.5に含まれています。
The functionality of location granularity reduction depends on the type of location provided as input. This document defines two profiles for reduction, namely:
ロケーションの粒度の削減の機能は、入力として提供されるロケーションのタイプによって異なります。このドキュメントでは、削減のために2つのプロファイルを定義しています。
o civic-transformation: If the <provide-location> element has a <provide-civic> child element, then civic location information is disclosed as described in Section 6.5.1, subject to availability.
o civic-transformation：<provide-location>要素に<provide-civic>子要素がある場合、6.5.1に記載されているように、都市の位置情報が公開されます。
o geodetic-transformation: If the <provide-location> element has a <provide-geo> child element, then geodetic location information is disclosed as described in Section 6.5.2, subject to availability.
o geodetic-transformation：<provide-location>要素に<provide-geo>子要素がある場合、測地位置情報は、セクション6.5.2で説明されているように公開されます。
The <provide-location> element MUST contain the 'profile' attribute if it contains child elements, and the child elements MUST be appropriate for the profile.
<provide-location>要素には、子要素が含まれている場合は「profile」属性が含まれている必要があり、子要素はプロファイルに適している必要があります。
If the <provide-location> element has no child elements, then civic as well as geodetic location information is disclosed without reducing its granularity, subject to availability. In this case, the profile attribute MUST NOT be included.
<provide-location>要素に子要素がない場合、可用性に応じて、粒度を低下させることなく、都市および測地の位置情報が開示されます。この場合、プロファイル属性を含めることはできません。
This profile uses the token 'civic-transformation'. This profile allows civic location transformations to be specified by means of the <provide-civic> element that restricts the level of civic location information the LS is permitted to disclose. The symbols of these levels are: 'country', 'region', 'city', 'building', and 'full'. Each level is given by a set of civic location data items such as <country> and <A1>, ..., <POM>, as defined in [RFC5139]. Each level includes all elements included by the lower levels.
このプロファイルでは、「civic-transformation」というトークンを使用します。このプロファイルでは、LSが公開を許可されている都市の場所情報のレベルを制限する<provide-civic>要素を使用して、都市の場所の変換を指定できます。これらのレベルの記号は、「国」、「地域」、「都市」、「建物」、「完全」です。 [RFC5139]で定義されているように、各レベルは、<country>や<A1>、...、<POM>などの一連の都市ロケーションデータ項目によって指定されます。各レベルには、下位レベルに含まれるすべての要素が含まれます。
The 'country' level includes only the <country> element; the 'region' level adds the <A1> element; the 'city' level adds the <A2> and <A3> elements; the 'building' level and the 'full' level add further civic location data as shown below.
「国」レベルには<country>要素のみが含まれます。 'region'レベルは<A1>要素を追加します。 'city'レベルは<A2>要素と<A3>要素を追加します。 「ビルディング」レベルと「フル」レベルは、以下に示すように、都市の位置データをさらに追加します。
full
{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>, <POD>,
<STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>, <NAM>, <FLR>,
<BLD>,<UNIT>,<ROOM>,<PLC>, <PCN>, <POBOX>, <ADDCODE>, <SEAT>
<RD>, <RDSEC>, <RDBR>, <RDSUBBR>, <PRM>, <POM>}
|
|
building
{<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>
<POD>, <STS>, <HNO>, <HNS>, <LMK>, <PC>,
<RD>, <RDSEC>, <RDBR>, <RDSUBBR> <PRM>, <POM>}
|
|
city
{<country>, <A1>, <A2>, <A3>}
|
|
region
{<country>, <A1>}
|
|
country
{<country>}
|
|
none
{}
The default value is "none".
デフォルト値は「なし」です。
The schema of the <provide-civic> element is defined in Section 8.
<provide-civic>要素のスキーマは、セクション8で定義されています。
This profile uses the token 'geodetic-transformation' and refers only to the Coordinate Reference System (CRS) WGS 84 (urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic location transformations to be specified by means of the <provide-geo> element that may restrict the returned geodetic location information based on the value provided in the 'radius' attribute. The value of the 'radius' attribute expresses the radius in meters.
このプロファイルは「geodetic-transformation」というトークンを使用し、座標参照系（CRS）WGS 84（urn：ogc：def：crs：EPSG :: 4326、2D）のみを参照します。このプロファイルでは、「radius」属性で指定された値に基づいて返される測地位置情報を制限する可能性がある<provide-geo>要素を使用して、測地位置変換を指定できます。 「半径」属性の値は、半径をメートルで表します。
The schema of the <provide-geo> element is defined in Section 8.
<provide-geo>要素のスキーマは、セクション8で定義されています。
The algorithm proceeds in six steps. The first two steps are independent of the measured position to be obscured and should be run only once or very infrequently for each region and desired uncertainty. The steps are:
アルゴリズムは6つのステップで進行します。最初の2つのステップは、覆い隠される測定位置とは無関係であり、各領域および必要な不確実性に対して1回だけまたは非常にまれに実行する必要があります。手順は次のとおりです。
1. Choose a geodesic projection with Cartesian coordinates and a surface you want to cover. Limit the worst-case distortion of the map as noted below.
1. デカルト座標とカバーしたい表面を持つ測地線投影を選択します。以下に示すように、マップのワーストケースの歪みを制限します。
2. Given a desired uncertainty radius "d", choose a grid of so-called "landmarks" at a distance of at least d units apart from each other.
2. 望ましい不確実性半径「d」が与えられた場合、いわゆる「ランドマーク」のグリッドを、互いから少なくともd単位の距離で選択します。
3. Given a measured location M=(m,n) on the surface, calculate its 4 closest landmarks on the grid, with coordinates: SW = (l,b), SE=(r,b), NW=(l,t), NE=(r,t). Thus, l<=m<r and b<=n<t. See notes below.
3. 表面上の測定された位置M =（m、n）を前提として、グリッド上でその4つの最も近いランドマークを座標で計算します：SW =（l、b）、SE =（r、b）、NW =（l、t） 、NE =（r、t）。したがって、l <= m <rおよびb <= n <tです。以下の注を参照してください。
4. Let x=(m-l)/(r-l) and y=(n-b)/(t-b).
4. x =（m-l）/（r-l）およびy =（n-b）/（t-b）とします。
x and y are thus the scaled local coordinates of the point M in the small grid square that contains it, where x and y range between 0 and 1.
したがって、xとyは、それを含む小さなグリッドスクエア内のポイントMのスケーリングされたローカル座標です。xとyの範囲は0〜1です。
5. Let p = 0.2887 (=sqrt(3)/6) and q = 0.7113 (=1-p). Determine which of the following eight cases holds:
5. p = 0.2887（= sqrt（3）/ 6）およびq = 0.7113（= 1-p）とします。次の8つのケースのどちらが成立するかを判断します。
C1. x < p and y < p
C2. p <= x < q and y < x and y < 1-x
C3. q <= x and y < p
C4. p <= y < q and x <= y and y < 1-x
C5. p <= y < q and y < x and 1-x <= y
C6. x < p and q <= y
C7. p <= x < q and x <= y and 1-x <= y
C8. q <= x and q <= y
6. Depending on the case, let C (=Center) be
6. 場合によっては、C（= Center）を
C1: SW C2: SW or SE C3: SE
C1：SW C2：SWまたはSE C3：SE
C4: SW or NW C5: SE or NE
C4：SWまたはNW C5：SEまたはNE
C6: NW C7: NW or NE C8: NE
C6：NW C7：NWまたはNE C8：NE
Return the circle with center C and radius d.
中心がC、半径がdの円を返します。
Notes:
ノート：
Regarding Step 1:
ステップ1について：
The scale of a map is the ratio of a distance (a straight line) on the map to the corresponding air distance on the ground. For maps covering larger areas, a map projection from a sphere (or ellipsoid) to the plane will introduce distortion, and the scale of the map is not constant. Also, note that the real distance on the ground is taken along great circles, which may not correspond to straight lines on the map, depending on the projection used. Let us measure the (length) distortion of the map as the quotient between the maximal and the minimal scales on the map. The distortion MUST be below 1.5. (The minimum distortion is 1.0: if the region of the map is small, then the scale may be taken as a constant over the whole map).
マップの縮尺は、マップ上の距離（直線）と対応する地上の空気距離の比率です。広い領域をカバーするマップの場合、球体（または楕円体）から平面へのマップ投影により歪みが生じ、マップの縮尺は一定ではありません。また、地上の実際の距離は大円に沿っているため、使用する投影法によっては地図上の直線に対応しない場合があります。マップの（長さ）歪みを、マップ上の最大スケールと最小スケールの間の商として測定してみましょう。歪みは1.5未満でなければなりません。 （最小の歪みは1.0です。マップの領域が小さい場合、縮尺はマップ全体で一定と見なされます）。
Regarding Step 3:
ステップ3について：
SW is mnemonic for southwest, b for bottom, l for left (SW=(l,b)), etc., but the directions of the geodesic projection may be arbitrary, and thus SW may not be southwest of M, but it will be left and below M *on the map*.
SWは南西のニーモニック、bは下、lは左（SW =（l、b））などですが、測地線投影の方向は任意であるため、SWはMの南西ではない可能性がありますが、 M *マップ*の左下にあります。
This section provides a few examples for authorization rules using the extensions defined in this document.
このセクションでは、このドキュメントで定義されている拡張機能を使用した承認ルールの例をいくつか示します。
This example illustrates a single rule that employs the civic location condition. It matches if the current location of the Target equals the content of the child elements of the <location> element. Requests match only if the Target is at a civic location with country set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 'Munich', city division (A4) set to 'Perlach', street name (A6) set to 'Otto-Hahn-Ring', and house number (HNO) set to '6'.
この例は、都市の場所の条件を使用する単一のルールを示しています。ターゲットの現在の場所が<location>要素の子要素のコンテンツと等しい場合に一致します。リクエストが一致するのは、ターゲットが都市の場所にあり、国が「ドイツ」に設定され、州（A1）が「バイエルン」に設定され、都市（A3）が「ミュンヘン」に設定され、都市区分（A4）が「Perlach」に設定されている場合のみです。ストリート名（A6）は 'Otto-Hahn-Ring'に設定され、番地（HNO）は '6'に設定されます。
No actions and transformation child elements are provided in this rule example. The actions and transformation could include presence-specific information when the Geolocation Policy framework is applied to the Presence Policy framework (see [RFC5025]).
このルールの例では、アクションと変換の子要素は提供されていません。位置情報ポリシーフレームワークがプレゼンスポリシーフレームワークに適用される場合、アクションと変換にはプレゼンス固有の情報が含まれる可能性があります（[RFC5025]を参照）。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56i09">
<conditions>
<gp:location-condition>
<gp:location
profile="civic-condition"
xml:lang="en"
label="Siemens Neuperlach site 'Legoland'"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A4>Perlach</A4>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
</gp:location>
</gp:location-condition>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
This example illustrates a rule that employs the geodetic location condition. The rule matches if the current location of the Target is inside the area specified by the polygon. The polygon uses the EPSG 4326 coordinate reference system. No altitude is included in this example.
この例は、測地位置条件を使用するルールを示しています。ルールは、ターゲットの現在の場所がポリゴンで指定された領域内にある場合に一致します。ポリゴンはEPSG 4326座標参照系を使用します。この例では高度は含まれていません。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset
xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<rule id="BB56A19">
<conditions>
<gp:location-condition>
<gp:location
xml:lang="en"
label="Sydney Opera House"
profile="geodetic-condition">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-33.8570029378 151.2150070761</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">1500
</gs:radius>
</gs:Circle>
</gp:location>
</gp:location-condition>
</conditions>
<transformations/>
</rule>
</ruleset>
This example illustrates a rule that employs a mixed civic and geodetic location condition. Depending on the available type of location information, namely civic or geodetic location information, one of the location elements may match.
この例は、都市と測地の位置の混合条件を使用するルールを示しています。利用可能なロケーション情報のタイプ、つまり、都市または測地のロケーション情報に応じて、ロケーション要素の1つが一致する場合があります。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset
xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<rule id="AA56i09">
<conditions>
<gp:location-condition>
<gp:location profile="civic-condition"
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A4>Perlach</A4>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
</gp:location>
<gp:location profile="geodetic-condition">
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.410649 150.87651</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">1500
</gs:radius>
</gs:Circle>
</gp:location>
</gp:location-condition>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
This example shows the transformations specified in this document. The <provide-civic> element indicates that the available civic location information is reduced to building level granularity. If geodetic location information is requested, then a granularity reduction is provided as well.
この例は、このドキュメントで指定されている変換を示しています。 <provide-civic>要素は、利用可能な都市の位置情報が建物レベルの粒度に削減されることを示しています。測地位置情報が要求された場合、粒度の削減も提供されます。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles">
<rule id="AA56i09">
<conditions/>
<actions/>
<transformations>
<gp:set-retransmission-allowed>false
</gp:set-retransmission-allowed>
<gp:set-retention-expiry>86400</gp:set-retention-expiry>
<gp:set-note-well xml:lang="en">My privacy policy goes here.
</gp:set-note-well>
<gp:keep-rule-reference>false
</gp:keep-rule-reference>
<gp:provide-location
profile="civic-transformation">
<lp:provide-civic>building</lp:provide-civic>
</gp:provide-location>
<gp:provide-location
profile="geodetic-transformation">
<lp:provide-geo radius="500"/>
</gp:provide-location>
</transformations> </rule> </ruleset> The following rule describes the shorthand notation for making the current location of the Target available to Location Recipients without granularity reduction.
</ transformations> </ rule> </ ruleset>次のルールは、ターゲットの現在の場所を、精度を落とさずに場所の受信者が利用できるようにするための省略表記を示しています。
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56ia9">
<conditions/>
<actions/>
<transformations>
<gp:provide-location/>
</transformations>
</rule>
</ruleset>
Suppose you want to obscure positions in the continental USA.
アメリカ本土でのポジションを曖昧にしたいとします。
Step 1:
ステップ1：
First, you choose a geodesic projection. If you are measuring location as latitude and longitude, a natural choice is to take a rectangular projection. One latitudinal degree corresponds to approximately 110.6 kilometers, while a good approximation of a longitudinal degree at latitude phi is (pi/180)*M*cos(phi), where pi is approximately 3.1415, and M is the Earth's average meridional radius, approximately 6,367.5 km. For instance, one longitudinal degree at 30 degrees (say, New Orleans) is 96.39 km, while the formula given offers an estimation of 96.24, which is good enough for our purposes.
最初に、測地線図法を選択します。場所を緯度と経度として測定している場合は、長方形の投影を使用するのが自然です。緯度1度は約110.6キロメートルに相当しますが、緯度phiでの経度の度数の適切な近似は（pi / 180）* M * cos（phi）です。ここで、piは約3.1415、Mは地球の平均子午線半径です。 6.367.5 km。たとえば、30度の縦方向の1度（たとえば、ニューオーリンズ）は96.39 kmですが、与えられた式は96.24の推定を提供します。これは、私たちの目的には十分です。
We will set up a grid not only for the continental USA, but for the whole earth between latitudes 25 and 50 degrees, and thus will cover also the Mediterranean, South Europe, Japan, and the north of China. As will be seen below, the grid distortion (for not too large grids in this region) is approx cos(25)/cos(50), which is 1.4099.
アメリカ大陸だけでなく、緯度25度から50度の間の地球全体にグリッドを設定し、地中海、南ヨーロッパ、日本、中国北部もカバーします。以下に示すように、グリッドの歪み（この領域のグリッドが大きすぎない場合）はおよそcos（25）/ cos（50）であり、1.4099です。
As origin of our grid, we choose the point at latitude 25 degrees and longitude 0 (Greenwich). The latitude 25 degrees is chosen to be just south of Florida and thus south of the continental USA. (On the Southern Hemisphere, the origin should be north of the region to be covered; if the region crosses the Equator, the origin should be on the Equator. In this way, it is guaranteed that the latitudinal degree has the largest distance at the latitude of the origin).
グリッドの起点として、緯度25度、経度0（グリニッジ）のポイントを選択します。緯度25度は、フロリダのちょうど南、したがって米国本土の南になるように選択されています。 （南半球では、原点はカバーされる領域の北である必要があります。領域が赤道を横切る場合、原点は赤道上である必要があります。このようにして、緯度が緯度で最大距離を持つことが保証されます。原点の緯度）。
At 25 degrees, one degree in east-west direction corresponds to approximately (pi/180)*M*cos(25) = 100.72 km.
25度では、東西方向の1度は約（pi / 180）* M * cos（25）= 100.72 kmに相当します。
The same procedure, basically, produces grids for
同じ手順で、基本的に、
* 45 degrees south to 45 degrees north: Tropics and subtropics, Africa, Australia
* 南45度から北45度：熱帯および亜熱帯、アフリカ、オーストラリア
* 25 to 50 degrees (both north or south): Continental United States, Mediterranean, most of China; most of Chile and Argentina, New Zealand
* 25〜50度（北または南の両方）：米国本土、地中海、ほとんどの中国。チリとアルゼンチンのほとんど、ニュージーランド
* 35 to 55 degrees (both north or south): Southern and Central Europe
* 35〜55度（北または南の両方）：南ヨーロッパおよび中央ヨーロッパ
* 45 to 60 degrees (both north or south): Central and Northern Europe, Canada
* 45〜60度（北または南の両方）：中央ヨーロッパおよび北ヨーロッパ、カナダ
* 55 to 65 degrees (both north or south): most of Scandinavia
* 55〜65度（北または南の両方）：スカンジナビアのほとんど
* 60 to 70 degrees (both north or south): Alaska
* 60〜70度（北または南の両方）：アラスカ
Since we do not want to change the grid system often (this would leak more information about obscured locations when they are repeatedly visited), the algorithm should prefer to use the grids discussed above, with origin at the Greenwich meridian and at latitudes o=0, o=25, o=35, o=45, 0=55, and o=60 degrees (north) or at latitudes o=-25, o=-35, o=-45, 0=-55, and o=-60 degrees (the minus to indicate "south").
グリッドシステムを頻繁に変更することは望まないため（繰り返しアクセスされると、不明瞭な場所に関する詳細情報がリークします）、アルゴリズムは、グリニッジ子午線と緯度o = 0を原点として、上記のグリッドを使用することをお勧めします。 、o = 25、o = 35、o = 45、0 = 55、o = 60度（北）または緯度o = -25、o = -35、o = -45、0 = -55、o = -60度（「南」を示すマイナス）。
Our choice for the continental USA is o=25.
米国本土での私たちの選択はo = 25です。
For locations close to the poles, a different projection should be used (not discussed here).
極に近い場所では、別の投影法を使用する必要があります（ここでは説明しません）。
Step 2:
ステップ2：
To construct the grid, we start with our chosen origin and place grid points at regular intervals along each of the axes (north-south and east-west) with a distance d between each.
グリッドを構築するには、選択した原点から始め、各軸（南北と東西）に沿って一定の間隔でグリッドポイントを配置します。
We will now construct a grid for a desired uncertainty of d = 100km. At our origin, 100 km correspond roughly to d1 = 100/ 100.72 = 0.993 degrees in an east-west direction and to d2 = 100/ 110.6 = 0.904 degrees in a north-south direction.
次に、d = 100kmの望ましい不確実性のグリッドを作成します。私たちの原点では、100 kmはおおよそ東西方向のd1 = 100 / 100.72 = 0.993度と南北方向のd2 = 100 / 110.6 = 0.904度に対応します。
The (i,j)-point in the grid (i and j are integers) has longitude d1*i and latitude 25+d2*j, measured in degrees. More generally, if the grid has origin at coordinates (0,o), measured in degrees, the (i,j)-point in the grid has coordinates (longitude = d1*i, latitude = o+d2*j). The grid has almost no distortion at the latitude of the origin, but it does as we go further away from it.
グリッド内の（i、j）ポイント（iおよびjは整数）は、経度d1 * iおよび緯度25 + d2 * jで、度単位で測定されます。より一般的には、グリッドの起点が座標（0、o）にあり、度単位で測定される場合、グリッドの（i、j）点は座標を持っています（経度= d1 * i、緯度= o + d2 * j）。グリッドには、原点の緯度ではほとんど歪みがありませんが、グリッドから離れるにつれて歪みが生じます。
The distance between two points in the grid at 25 degrees latitude is indeed approximately 100 km, but just above the Canadian border, on the 50th degree, it is 0.993*(pi/180)*M*cos(50) = 70.92km. Thus, the grid distortion is 100/70.92 = 1.41, which is acceptable (<1.5). (In the north-south direction, the grid has roughly no distortion; the vertical distance between two neighboring grid points is approximately 100 km).
緯度25度のグリッド内の2点間の距離は確かに約100 kmですが、50度のカナダ国境の真上では、0.993 *（pi / 180）* M * cos（50）= 70.92kmです。したがって、グリッドの歪みは100 / 70.92 = 1.41であり、許容可能です（<1.5）。 （南北方向では、グリッドにはほぼ歪みがありません。隣接する2つのグリッドポイント間の垂直距離は約100 kmです）。
Step 3:
ステップ3：
Now suppose you measure a position at M, with longitude -105 (the minus sign is used to denote 105 degrees *west*; without minus, the point is in China, 105 degrees east) and latitude 40 degrees (just north of Denver, CO). The point M is 105 degrees west and 15 degrees north of our origin (which has longitude 0 and latitude 25).
ここで、経度-105（マイナス記号は105度*西*を示すために使用されます。マイナスなしで、ポイントは中国にあり、東105度）と緯度40度（デンバーのちょうど北、 CO）。点Mは、原点（経度0、緯度25）の西105度、北15度です。
Let "floor" be the function that returns the largest integer smaller or equal to a floating point number. To calculate SW, the closest point of the grid on the southwest of M=(m,n), we calculate
「floor」を、浮動小数点数以下の最大の整数を返す関数とします。 SWを計算するには、M =（m、n）の南西にあるグリッドの最も近い点を計算します。
i= floor(m/d1) = floor(-105/0.993) = -106
j= floor(n-o/d2) = floor(15/0.904) = 16
Those are the indexes of SW on the grid. The coordinates of SW
are then: (d1*i, 25+d2*j) = (-105.242, 39.467).
Thus:
したがって：
l=d1*floor(m/d1) = -105.243
r=l+d1 = -105.243+0.993 = -104.250
b=o+d2*floor(n-o/d2) = 39.467
t=b+d2 = 39.467+0.904 = 40.371
These are the formulas for l, r, b, and t in the general case of Cartesian projections based on latitude and longitude.
これらは、緯度と経度に基づくデカルト投影の一般的な場合のl、r、b、およびtの式です。
Step 4:
ステップ4：
Calculate x and y, the local coordinates of the point M in the small grid square that contains it. This is easy:
xとyを計算します。xとyは、それを含む小さなグリッドの正方形の点Mのローカル座標です。これは簡単：
x=(m-l)/(r-l) = [-105 -(-105.243)]/0.993 = 0.245
y=(n-b)/(t-b) = [40 - 39.467]/0.904 = 0.590
Step 5:
ステップ5：
First, compare x with p (0.2887) and 1-p (0.7113). x is smaller than p. Therefore, only cases 1, 4, or 6 could hold.
最初に、xをp（0.2887）および1-p（0.7113）と比較します。 xはpより小さい。したがって、ケース1、4、または6のみが成立します。
Also, compare y with p (0.2887) and 1-p (0.7113). y is between them: p <= y < q. Thus, we must be in case 4. To check, compare y (0.59) with x (0.245) and 1-x. y is larger than x and smaller than 1-x. We are in case C4 (p <= y < q and x <= y and y < 1-x).
また、yをp（0.2887）および1-p（0.7113）と比較します。 yはそれらの間にあります：p <= y <q。したがって、ケース4でなければなりません。確認するには、y（0.59）をx（0.245）および1-xと比較します。 yはxより大きく、1-xより小さい。ケースC4です（p <= y <qおよびx <= yおよびy <1-x）。
Step 6:
ステップ6：
Now we choose either SW or NW as the center of the circle.
次に、円の中心としてSWまたはNWを選択します。
The obscured location is the circle with radius 100 km and center in SW (coordinates: -105.243, 39.467) or NW (coordinates: -105.243, 40.371).
隠された場所は、半径100 kmの円で、中心が南西（座標：-105.243、39.467）または北西（座標：-105.243、40.371）です。
This section defines the location profiles used as child elements of the transformation element.
このセクションでは、transformationエレメントの子エレメントとして使用されるロケーションプロファイルを定義します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:basic-location-profiles"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- profile="civic-transformation" -->
<xs:element name="provide-civic" default="none">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="full"/>
<xs:enumeration value="building"/>
<xs:enumeration value="city"/>
<xs:enumeration value="region"/>
<xs:enumeration value="country"/>
<xs:enumeration value="none"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<!-- profile="geodetic-transformation" -->
<xs:element name="provide-geo">
<xs:complexType>
<xs:attribute name="radius" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xs:schema>
This section presents the XML schema that defines the Geolocation Policy schema described in this document. The Geolocation Policy schema extends the Common Policy schema (see [RFC4745]).
このセクションでは、このドキュメントで説明されている位置情報ポリシースキーマを定義するXMLスキーマを示します。位置情報ポリシースキーマは、共通ポリシースキーマを拡張します（[RFC4745]を参照）。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- Import Common Policy-->
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- Geopriv Conditions -->
<xs:element name="location-condition"
type="gp:locationconditionType"/>
<xs:complexType name="locationconditionType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="location" type="gp:locationType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="locationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="profile" type="xs:string"/>
<xs:attribute name="label" type="xs:string"/>
<xs:attribute ref="xml:lang" />
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- Geopriv transformations -->
<xs:element name="set-retransmission-allowed"
type="xs:boolean" default="false"/>
<xs:element name="set-retention-expiry"
type="xs:integer" default="0"/>
<xs:element name="set-note-well"
type="gp:notewellType"/>
<xs:element name="keep-rule-reference"
type="xs:boolean" default="false"/>
<xs:element name="provide-location"
type="gp:providelocationType"/>
<xs:complexType name="notewellType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="providelocationType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="profile" type="xs:string" />
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
This section defines the details necessary for clients to manipulate geolocation privacy documents from a server using XCAP. If used as part of a presence system, it uses the same Application Unique ID (AUID) as those rules. See [RFC5025] for a description of the XCAP usage in context with presence authorization rules.
このセクションでは、クライアントがXCAPを使用してサーバーからジオロケーションプライバシードキュメントを操作するために必要な詳細を定義します。プレゼンスシステムの一部として使用する場合、これらのルールと同じアプリケーション固有ID（AUID）を使用します。プレゼンス認証ルールに関連するXCAPの使用法については、[RFC5025]を参照してください。
XCAP requires application usages to define a unique Application Unique ID (AUID) in either the IETF tree or a vendor tree. This specification defines the "geolocation-policy" AUID within the IETF tree, via the IANA registration in Section 11.
XCAPでは、アプリケーションを使用して、IETFツリーまたはベンダーツリーで一意のアプリケーションユニークID（AUID）を定義する必要があります。この仕様では、セクション11のIANA登録により、IETFツリー内の「geolocation-policy」AUIDを定義しています。
XCAP requires application usages to define a schema for their documents. The schema for geolocation authorization documents is described in Section 9.
XCAPでは、ドキュメントのスキーマを定義するためにアプリケーションを使用する必要があります。地理位置情報承認ドキュメントのスキーマについては、セクション9で説明します。
XCAP requires application usages to define the default namespace for their documents. The default namespace is urn:ietf:params:xml:ns:geolocation-policy.
XCAPでは、ドキュメントのデフォルトの名前空間を定義するためにアプリケーションを使用する必要があります。デフォルトの名前空間はurn：ietf：params：xml：ns：geolocation-policyです。
XCAP requires application usages to define the MIME media type for documents they carry. Geolocation privacy authorization documents inherit the MIME type of Common Policy documents, application/ auth-policy+xml.
XCAPでは、アプリケーションが使用するドキュメントのMIMEメディアタイプを定義する必要があります。位置情報プライバシー認証ドキュメントは、共通ポリシードキュメントのMIMEタイプであるapplication / auth-policy + xmlを継承します。
This specification does not define additional constraints.
この仕様では、追加の制約は定義されていません。
This document discusses the semantics of a geolocation privacy authorization.
このドキュメントでは、地理位置情報のプライバシー認証のセマンティクスについて説明します。
When a Location Server receives a request to access location information of some user foo, it will look for all documents within http://[xcaproot]/geolocation-policy/users/foo and use all documents found beneath that point to guide authorization policy.
ロケーションサーバーがユーザーfooのロケーション情報へのアクセス要求を受信すると、http：// [xcaproot] / geolocation-policy / users / foo内のすべてのドキュメントを検索し、そのポイントの下にあるすべてのドキュメントを使用して承認ポリシーを導きます。
This application usage does not define additional resource interdependencies.
このアプリケーションの使用法は、追加のリソースの相互依存関係を定義していません。
This application usage does not modify the default XCAP authorization policy, which is that only a user can read, write, or modify his/her own documents. A server can allow privileged users to modify documents that they do not own, but the establishment and indication of such policies is outside the scope of this document.
このアプリケーションの使用は、デフォルトのXCAP承認ポリシーを変更しません。つまり、ユーザーだけが自分のドキュメントを読み取り、書き込み、または変更できます。サーバーは特権ユーザーが自分が所有していないドキュメントを変更することを許可できますが、そのようなポリシーの確立と表示はこのドキュメントの範囲外です。
There are several IANA considerations associated with this specification.
この仕様に関連するIANAの考慮事項がいくつかあります。
This section registers an XML schema in the IETF XML Registry as per the guidelines in [RFC3688].
このセクションは、[RFC3688]のガイドラインに従って、IETF XMLレジストリにXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:geolocation-policy
Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), Hannes Tschofenig (hannes.tschofenig@nsn.com).
登録者の連絡先：IETF Geoprivワーキンググループ（geopriv@ietf.org）、Hannes Tschofenig（hannes.tschofenig@nsn.com）。
XML: The XML schema to be registered is contained in Section 9. Its first line is
XML：登録されるXMLスキーマはセクション9に含まれています。その最初の行は
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
そして最後の行は
</xs:schema>
This section registers a new XML namespace in the IETF XML Registry as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、IETF XMLレジストリに新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:geolocation-policy
Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), Hannes Tschofenig (hannes.tschofenig@nsn.com).
登録者の連絡先：IETF Geoprivワーキンググループ（geopriv@ietf.org）、Hannes Tschofenig（hannes.tschofenig@nsn.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Geolocation Policy Namespace</title>
</head>
<body>
<h1>Namespace for Geolocation Authorization Policies</h1>
<h2>urn:ietf:params:xml:schema:geolocation-policy</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6772.txt">
RFC 6772</a>.</p>
</body>
</html>
END
This document creates a registry of location profile names for the Geolocation Policy framework. Profile names are XML tokens. This registry will operate in accordance with RFC 5226 [RFC5226], Specification Required.
このドキュメントは、位置情報ポリシーフレームワークの位置プロファイル名のレジストリを作成します。プロファイル名はXMLトークンです。このレジストリは、RFC 5226 [RFC5226]、Specification Requiredに従って動作します。
This document defines the following profile names:
このドキュメントでは、次のプロファイル名を定義しています。
geodetic-condition: Defined in Section 4.1. civic-condition: Defined in Section 4.2. geodetic-transformation: Defined in Section 6.5.2. civic-transformation: Defined in Section 6.5.1.
geodetic-condition：セクション4.1で定義。 civic-condition：セクション4.2で定義。 geodetic-transformation：セクション6.5.2で定義。 civic-transformation：セクション6.5.1で定義。
This section registers an XML schema in the IETF XML Registry as per the guidelines in [RFC3688].
このセクションは、[RFC3688]のガイドラインに従って、IETF XMLレジストリにXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:basic-location-profiles
Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), Hannes Tschofenig (hannes.tschofenig@nsn.com).
登録者の連絡先：IETF Geoprivワーキンググループ（geopriv@ietf.org）、Hannes Tschofenig（hannes.tschofenig@nsn.com）。
XML: The XML schema to be registered is contained in Section 8. Its first line is
XML：登録されるXMLスキーマはセクション8に含まれています。その最初の行は
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
そして最後の行は
</xs:schema>
This section registers a new XML namespace in the IETF XML Registry as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、IETF XMLレジストリに新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:basic-location-profiles
Registrant Contact: IETF Geopriv Working Group (geopriv@ietf.org), Hannes Tschofenig (hannes.tschofenig@nsn.com).
登録者の連絡先：IETF Geoprivワーキンググループ（geopriv@ietf.org）、Hannes Tschofenig（hannes.tschofenig@nsn.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Basic Location Profile Namespace</title>
</head>
<body>
<h1>Namespace for Basic Location Profile</h1>
<h2>urn:ietf:params:xml:schema:basic-location-profiles</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6772.txt">
RFC 6772</a>.</p>
</body>
</html>
END
This section registers an XCAP Application Unique ID (AUID) in the "XML-XCAP Application Unique IDs" registry according to the IANA procedures defined in [RFC4825].
このセクションでは、[RFC4825]で定義されているIANA手順に従って、XCAPアプリケーション固有ID（AUID）を「XML-XCAPアプリケーション固有ID」レジストリに登録します。
Name of the AUID: geolocation-policy Description: Geolocation privacy rules are documents that describe the permissions that a Target has granted to Location Recipients that access information about his/her geographic location.
AUIDの名前：geolocation-policy説明：ジオロケーションプライバシールールは、ターゲットが地理的位置に関する情報にアクセスするロケーション受信者に付与した権限を説明するドキュメントです。
The policies described in this document are mostly meant for machine-to-machine communications; as such, many of its elements are tokens not meant for direct human consumption. If these tokens are presented to the end user, some localization may need to occur. The policies are, however, supposed to be created with the help of humans, and some of the elements and attributes are subject to internationalization considerations. The content of the <label> element is meant to be provided by a human (the Rule Maker) and also displayed to a human. Furthermore, the location condition element (<location-condition>, using the civic location profile, see Section 4.2) and the <set-note-well> element (see Section 6.3) may contain non-US-ASCII letters.
このドキュメントで説明されているポリシーは、主にマシン間の通信を対象としています。そのため、その要素の多くは、人間が直接消費することを目的としていないトークンです。これらのトークンがエンドユーザーに提示される場合、ローカライズが必要になる場合があります。ただし、ポリシーは人間の助けを借りて作成されることになっており、要素や属性の一部は国際化の考慮事項の対象となります。 <label>要素のコンテンツは、人間（ルールメーカー）によって提供され、人間にも表示されるようになっています。さらに、場所の条件要素（<location-condition>、市民の場所のプロファイルを使用、セクション4.2を参照）および<set-note-well>要素（セクション6.3を参照）には、US-ASCII以外の文字が含まれる場合があります。
The geolocation policies utilize XML, and all XML processors are required to understand UTF-8 and UTF-16 encodings. Therefore, all entities processing these policies MUST understand UTF-8- and UTF-16- encoded XML. Additionally, geolocation policy-aware entities MUST NOT encode XML with encodings other than UTF-8 or UTF-16.
地理位置情報ポリシーはXMLを利用し、すべてのXMLプロセッサはUTF-8およびUTF-16エンコーディングを理解する必要があります。したがって、これらのポリシーを処理するすべてのエンティティは、UTF-8およびUTF-16でエンコードされたXMLを理解する必要があります。さらに、地理位置情報ポリシー対応エンティティは、XMLをUTF-8またはUTF-16以外のエンコードでエンコードしてはなりません（MUST NOT）。
This document aims to allow users to prevent unauthorized access to location information and to restrict access to information dependent on the location of the Target, using location-based conditions. This is accomplished using authorization policies. This work builds on a series of other documents: security requirements are described in [RFC6280] and a discussion of generic security threats is available with [RFC3694]. Aspects of combining permissions in cases of multiple occurrence are addressed in [RFC4745].
このドキュメントは、ロケーションベースの条件を使用して、ユーザーがロケーション情報への不正アクセスを防止し、ターゲットのロケーションに依存する情報へのアクセスを制限できるようにすることを目的としています。これは、許可ポリシーを使用して実現されます。この作業は、一連の他のドキュメントに基づいています。セキュリティ要件は[RFC6280]で説明されており、一般的なセキュリティ脅威の説明は[RFC3694]で利用できます。複数回発生する場合の権限の組み合わせの側面は、[RFC4745]で対処されています。
In addition to the authorization policies, mechanisms for obfuscating location information are described. A theoretical treatment of location obfuscation is provided in [DUCKHAM05] and in [IFIP07]. [DUCKHAM05] provides the foundation, and [IFIP07] illustrates three different types of location obfuscation by enlarging the radius, by shifting the center, and by reducing the radius. The algorithm in Section 6.5.2 for geodetic location information obfuscation uses these techniques.
認可ポリシーに加えて、位置情報を難読化するメカニズムについても説明します。ロケーション難読化の理論的な扱いは、[DUCKHAM05]と[IFIP07]で提供されています。 [DUCKHAM05]は基盤を提供し、[IFIP07]は、半径を大きくすること、中心をシフトすること、および半径を小さくすることによって、3つの異なるタイプの場所の難読化を示しています。測地位置情報の難読化に関するセクション6.5.2のアルゴリズムは、これらの手法を使用します。
The requirements for protecting privacy-sensitive location information vary. The two obfuscation algorithms in this document provide a basis for protecting against unauthorized disclosure of location information, but they have limitations. Application and user requirements vary widely; therefore, an extension mechanism is support for defining and using different algorithms.
プライバシーに敏感な位置情報を保護するための要件はさまざまです。このドキュメントの2つの難読化アルゴリズムは、位置情報の不正な開示から保護するための基礎を提供しますが、制限があります。アプリケーションとユーザーの要件は大きく異なります。したがって、拡張メカニズムは、さまざまなアルゴリズムを定義して使用するためのサポートです。
Whenever location information is returned to a Location Recipient, it contains the location of the Target. This is also true when location is obfuscated, i.e., the Location Server does not lie about the Target's location but instead hides it within a larger location shape. Even without the Target's movement, there is a danger that information will be revealed over time. While the Target's location is not revealed within a particular region of the grid, the size of that returned region matters as well as the precise location of the Target within that region. Returning location shapes that are randomly computed will over time reveal more and more information about the Target.
ロケーション情報がロケーション受信者に返されるときは常に、ターゲットのロケーションが含まれています。これは、場所が難読化されている場合にも当てはまります。つまり、ロケーションサーバーがターゲットの場所について嘘をついているのではなく、より大きな場所の形状内で非表示になっています。ターゲットの動きがなくても、時間の経過とともに情報が漏洩する危険があります。ターゲットの位置はグリッドの特定の領域内では明らかにされませんが、返される領域のサイズと、その領域内のターゲットの正確な位置が重要です。ランダムに計算された場所の形状を返すと、時間の経過とともにターゲットに関する情報がますます明らかになります。
Consider Figure 1, which shows three ellipses, a dotted area in the middle, and the Target's true location marked as 'x'. The ellipses illustrate the location shapes as received by a potential Location Recipient over time for requests of a Target's location information. Collecting information about the returned location information over time allows the Location Recipient to narrow the potential location of the Target down to the dotted area in the center of the graph.
3つの楕円、中央に点線の領域、「x」とマークされたターゲットの実際の位置を示す図1を考えてみます。楕円は、ターゲットの位置情報のリクエストに対して、時間の経過とともに潜在的な位置受信者が受信する位置形状を示しています。時間の経過とともに返された位置情報に関する情報を収集することで、位置受信者はターゲットの潜在的な位置をグラフの中央の点線の領域に絞り込むことができます。
For this purpose, the algorithm described in Section 6.5.2 uses a
grid that ensures the same location information is reported while the
Target remains in the same geographical area.
,-----.
,----,-'. `-.
,-' / `-. \
,' / _...._ `. \
/ ,-'......`._\ :
; /|...........\: |
| / :.....x......+ ;
: | \...........;| /
\ | \........./ | /
`. \ `-.....,' ,''
'-.\ `-----'|
``.-----' ,'
`._ _,'
`'''
Figure 1: Obfuscation: A Static Target
図1：難読化：静的ターゲット
An obscuring method that returns different results for consecutive requests can be exploited by recipients wishing to use this property. Rate limiting the generation of new obscured locations or providing the same obscured location to recipients for the same location might limit the information that can be obtained. Note, however, that providing a new obscured location based on a change in location provides some information to recipients when they observe a change in location.
連続したリクエストに対して異なる結果を返す不明瞭なメソッドは、このプロパティを使用したい受信者によって悪用される可能性があります。新しい隠された場所の生成をレート制限したり、同じ場所の受信者に同じ隠された場所を提供したりすると、取得できる情報が制限される場合があります。ただし、場所の変更に基づいて新しい隠された場所を提供すると、受信者が場所の変更を観察したときにいくつかの情報が提供されます。
When the Target is moving, then the location transformations reveal information when switching from one privacy region to another one. For example, when a transformation indicates that civic location is provided at a 'building' level of granularity, floor levels, room numbers, and other details normally internal to a building would be hidden. However, when the Target moves from one building to the next one, then the movement would still be recognizable as the disclosed location information would be reflected by the new civic location information indicating the new building. With additional knowledge about building entrances and floor plans, it would be possible to learn additional information.
ターゲットが移動している場合、位置変換により、あるプライバシー領域から別のプライバシー領域に切り替えるときに情報が明らかになります。たとえば、変換によって都市の場所が「建物」レベルの粒度で提供されることが示される場合、通常は建物内部のフロアレベル、部屋番号、およびその他の詳細が非表示になります。ただし、ターゲットが1つの建物から次の建物に移動しても、公開された位置情報は新しい建物を示す新しい市民の位置情報に反映されるため、移動は依然として認識可能です。建物の入り口とフロアプランに関する追加の知識があれば、追加の情報を学ぶことができます。
The algorithm presented in Section 6.5.2 has some issues where information is leaked: when moving, when switching from one privacy region to another one, and also when the user regularly visits the same location.
セクション6.5.2に示すアルゴリズムには、情報が漏洩するという問題があります。移動するとき、あるプライバシー領域から別のプライバシー領域に切り替えるとき、およびユーザーが定期的に同じ場所にアクセスするときです。
The first issue arises if the algorithm provides different location information (privacy region) only when the previous one becomes inapplicable. The algorithm discloses new information the moment that the Target is on the border of the old privacy region.
最初の問題は、前の情報が適用されなくなったときにのみ、アルゴリズムが異なる位置情報（プライバシー領域）を提供する場合に発生します。アルゴリズムは、ターゲットが古いプライバシー領域の境界にある瞬間に新しい情報を開示します。
Another issue arises if the algorithm produces the different values for the same location that is repeatedly visited. Suppose a user goes home every night. If the reported obfuscated locations are all randomly chosen, an analysis can reveal the home location with high precision.
アルゴリズムが、繰り返しアクセスされる同じ場所に対して異なる値を生成する場合、別の問題が発生します。ユーザーが毎晩家に帰るとします。報告された難読化された場所がすべてランダムに選択されている場合、分析によりホームの場所が高精度で明らかになる可能性があります。
In addition to these concerns, the combination of an obscured location with public geographic information (highways, lakes, mountains, cities, etc.) may yield much more precise location information than is desired. But even without it, just observing movements, once or multiple times, any obscuring algorithm can leak information about velocities or positions. Suppose a user wants to disclose location information with a radius of r. The privacy region, a circle with that radius, has an area of A = pi * r^2. An adversary, observing the movements, will deduce that the target is visiting, was visiting, or regularly visits, a region of size A1, smaller than A. The ratio A1/A should be, even in the worst case, larger than a fixed known number, in order that the user can predict the worst-case information leakage. The choices of Section 6.5.2 are such that this maximum leakage can be established: by any statistical procedures, without using external information (highways, etc., as discussed above), the quotient A1/A is larger than 0.13 (= 1/(5*1.5) ). Thus, for instance, when choosing a provided location of size 1000 km^2, he will be leaking, in worst case, the location within a region of size 130 km^2.
これらの懸念に加えて、不明瞭な場所と公共の地理情報（高速道路、湖、山、都市など）を組み合わせると、必要以上に正確な場所情報が得られる場合があります。しかし、それがなくても、動きを1回または複数回観察するだけで、不明瞭化アルゴリズムは速度や位置に関する情報を漏洩する可能性があります。ユーザーが半径rの位置情報を公開したいとします。その半径の円であるプライバシー領域の面積は、A = pi * r ^ 2です。動きを観察している敵は、ターゲットがA、Aより小さいサイズA1の領域を訪問している、訪問していた、または定期的に訪問していると推測します。A1/ Aの比率は、最悪の場合でも、固定よりも大きい必要があります既知の数。ユーザーが最悪の場合の情報漏えいを予測できるようにするため。セクション6.5.2の選択は、この最大リークを確立できるようにするものです。外部情報（上記のように高速道路など）を使用せずに、統計的手順により、商A1 / Aが0.13（= 1 / （5 * 1.5））。したがって、たとえば、1000 km ^ 2のサイズの提供された場所を選択すると、最悪の場合、130 km ^ 2の領域内の場所がリークします。
There is the risk that end users are specifying their location-based policies in such a way that very small changes in location yields a significantly different level of information disclosure. For example, a user might want to set authorization policies differently when they are in a specific geographical area (e.g., at home, in the office). Location might be the only factor in the policy that triggers a very different action and transformation to be executed. The accuracy of location information is not always sufficient to unequivocally determine whether a location is within a specific boundary [GEOPRIV-UNCERTAINTY]. In some situations, uncertainty in location information could produce unexpected results for end users. Providing adequate user feedback about potential errors arising from these limitation can help prevent unintentional information leakage.
エンドユーザーが場所ベースのポリシーを指定し、場所のごくわずかな変更でも情報開示のレベルが大幅に異なるというリスクがあります。たとえば、ユーザーが特定の地理的領域（自宅やオフィスなど）にいるときは、承認ポリシーを別の方法で設定したい場合があります。ロケーションは、非常に異なるアクションと変換の実行をトリガーするポリシーの唯一の要素である可能性があります。位置情報の正確さは、位置が特定の境界内にあるかどうかを明確に判断するのに必ずしも十分ではありません[GEOPRIV-UNCERTAINTY]。状況によっては、位置情報の不確実性がエンドユーザーに予期しない結果をもたらす可能性があります。これらの制限に起因する潜在的なエラーに関する適切なユーザーフィードバックを提供することで、意図しない情報漏えいを防ぐことができます。
Users might create policies that are nonsensical. To avoid such cases, the software used to create the authorization policies should perform consistency checks, and when authorization policies are uploaded to the policy servers, then further checks can be performed. When XCAP is used to upload authorization policies, then built-in features of XCAP can be utilized to convey error messages back to the user about an error condition. Section 8.2.5 of [RFC4825] indicates that some degree of application-specific checking is provided when authorization policies are added, modified, or deleted. The XCAP protocol may return a 409 response with a response that may contain a detailed conflict report containing the <constraint-failure> element. A human-readable description of the problem can be indicated in the 'phrase' attribute of that element.
ユーザーが無意味なポリシーを作成する場合があります。このような場合を回避するには、許可ポリシーの作成に使用するソフトウェアで整合性チェックを実行し、許可ポリシーがポリシーサーバーにアップロードされると、さらにチェックを実行できます。 XCAPを使用して承認ポリシーをアップロードする場合、XCAPの組み込み機能を利用して、エラー条件に関するエラーメッセージをユーザーに返すことができます。 [RFC4825]のセクション8.2.5は、承認ポリシーが追加、変更、または削除されたときに、ある程度のアプリケーション固有のチェックが提供されることを示しています。 XCAPプロトコルは、<constraint-failure>要素を含む詳細な競合レポートを含む可能性がある応答を含む409応答を返す場合があります。人間が読める形式の問題の説明は、その要素の「phrase」属性で示すことができます。
Location-obscuring attempts to remove information about the location of a Target. The effectiveness of location obscuring is determined by how much uncertainty a Location Recipient has about the location of the Target. A location-obscuring algorithm is effective if the Location Recipient cannot recover a location with better uncertainty than the obscuring algorithm was instructed to add.
場所の不明瞭化は、ターゲットの場所に関する情報を削除しようとします。場所の隠蔽の有効性は、場所の受信者がターゲットの場所についてどれだけ不確実であるかによって決まります。場所の隠蔽アルゴリズムは、場所の受信者が追加を指示する隠蔽アルゴリズムよりも不確実性が高い場所を復元できない場合に効果的です。
Effective location obscuring is difficult. The amount of information that can be recovered by a determined and resourceful Location Recipient can be considerably more than is immediately apparent. A concise summary of the challenges is included in [DUCKHAM10].
効果的な場所を隠すことは困難です。決定的で機知に富んだ場所の受信者が回復できる情報の量は、すぐにわかる量よりもかなり多くなる可能性があります。課題の簡潔な要約は、[DUCKHAM10]に含まれています。
A Location Recipient in possession of external information about the Target or geographical area that is reported can make assumptions or guesses aided by that information to recover more accurate location information. This is true even when a single location is reported, but it is especially true when multiple locations are reported for the same Target over time.
報告されたターゲットまたは地理的領域に関する外部情報を所持しているロケーション受信者は、その情報に基づいて推測または推測を行い、より正確なロケーション情報を復元できます。これは、1つの場所が報告された場合でも当てはまりますが、同じターゲットに対して複数の場所が報告された場合は特にそうです。
Furthermore, a Location Recipient that attempts to recover past locations for a Target can use later-reported locations to further refine any recovered location. A location-obscuring algorithm typically does not have any information about the future location of the Target.
さらに、ターゲットの過去の場所を復元しようとする場所受信者は、後で報告された場所を使用して、復元された場所をさらに絞り込むことができます。場所を隠すアルゴリズムには、通常、ターゲットの将来の場所に関する情報はありません。
The degree to which location information can be effectively degraded by an obscuring algorithm depends on the information that is used by the obscuring algorithm. If the information available to the obscuring algorithm is both more extensive and more effectively employed than the information available to the Location Recipient, then location obscuring might be effective.
隠蔽アルゴリズムによって位置情報が効果的に低下する度合いは、隠蔽アルゴリズムによって使用される情報によって異なります。隠蔽アルゴリズムで使用できる情報が、ロケーション受信者で使用できる情報よりも広範囲で効果的に使用されている場合は、ロケーション隠蔽が有効な場合があります。
Obscured locations can still serve a purpose where a Location Recipient is willing to respect privacy. A privacy-respecting Location Recipient can choose to interpret the existence of uncertainty as a request from a Rule Maker to not recover location.
隠された場所は、場所の受信者がプライバシーを尊重する意思がある場合でも、目的を果たすことができます。プライバシーを尊重するロケーション受信者は、不確実性の存在をルールメーカーからのロケーションを回復しないように要求するものとして解釈することを選択できます。
Location obscuring is unlikely to be effective against a more determined or resourceful adversary. Withholding location information entirely is perhaps the most effective method of ensuring that it is not recovered.
ロケーションの不明瞭化は、より決定的な、または機知に富んだ敵に対して効果的である可能性は低いです。位置情報を完全に保留することは、おそらくそれが回復されないようにするための最も効果的な方法です。
As a final caution, we note that omitted data also conveys some information. Selective withholding of information reveals that there is something worth hiding. That information might be used to reveal something of the information that is being withheld. For example, if location is only obscured around a user's home and office, then the lack of location for that user and the current time will likely mean that the user is at home at night and in the office during the day, defeating the purpose of the controls.
最後の注意として、省略されたデータもいくつかの情報を伝えることに注意してください。情報を選択的に差し控えると、何かを隠す価値があることがわかります。その情報は、差し控えられている情報の一部を明らかにするために使用される可能性があります。たとえば、場所がユーザーの自宅とオフィスの周りのみに隠れている場合、そのユーザーと現在の時間の場所がないことは、ユーザーが夜は自宅にいて、日中はオフィスにいることを意味し、コントロール。
[GML] OpenGIS, "OpenGIS Geography Markup Language (GML) Implementation Specification, Version 3.1.1, OGC 03-105r1", July 2004, <http://portal.opengeospatial.org/files/ ?artifact_id=4700>.
[GML] OpenGIS、「OpenGIS Geography Markup Language（GML）実装仕様、バージョン3.1.1、OGC 03-105r1」、2004年7月、<http://portal.opengeospatial.org/files/？artifact_id = 4700>。
[NIMA.TR8350.2-3e] "Department of Defense (DoD) World Geodetic System 1984 (WGS 84), Third Edition", NIMA TR8350.2, January 2000.
[NIMA.TR8350.2-3e]「国防総省（DoD）世界測地システム1984（WGS 84）、第3版」、NIMA TR8350.2、2000年1月。
[OGC-06-103r4] OpenGIS, "OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture", May 2011, <http://www.opengeospatial.org/standards/sfa?>.
[OGC-06-103r4] OpenGIS、「OpenGIS Implementation Specification for Geographic information-Simple feature access-Part 1：Common architecture」、2011年5月、<http://www.opengeospatial.org/standards/sfa？>。
[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月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[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、「Common Policy：A Document Format for Expressing Privacy Preferences」、RFC 4745、2月2007年
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「GEOPRIV Presence Information Data Format Location Object（PIDF-LO）Usage Clarification、Considerations、and Recommendations」、RFC 5491、2009年3月。
[DUCKHAM05] Duckham, M. and L. Kulik, "A Formal Model of Obfuscation and Negotiation for Location Privacy", In Proc. of the 3rd International Conference PERVASIVE 2005, Munich, Germany, May 2005.
[DUCKHAM05] Duckham、M。、およびL. Kulik、「ロケーションプライバシーの難読化および交渉の正式なモデル」、Proc。第3回国際会議PERVASIVE 2005、ドイツ、ミュンヘン、2005年5月の。
[DUCKHAM10] Duckham, M., "Moving Forward: Location Privacy and Location Awareness", In Proc. 3rd ACM SIGSPATIAL Workshop on Security and Privacy in GIS and LBS (SPRINGL), ACM, November 2010.
[DUCKHAM10]ダッカムM.、「前進：ロケーションプライバシーとロケーション認識」、Proc。第3回ACM SIGSPATIALワークショップ、GISおよびLBSのセキュリティとプライバシー（SPRINGL）、ACM、2010年11月。
[GEO-SHAPE] Thomson, M., "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", Work in Progress, December 2006.
[GEO-SHAPE] Thomson, M., "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", Work in Progress, December 2006.
[GEOPRIV-UNCERTAINTY] Thomson, M. and J. Winterbottom, "Representation of Uncertainty and Confidence in PIDF-LO", Work in Progress, March 2012.
[GEOPRIV-UNCERTAINTY] Thomson、M.およびJ. Winterbottom、「PIDF-LOにおける不確実性と信頼性の表現」、2012年3月、進行中。
[IFIP07] Ardagna, C., Cremonini, M., Damiani, E., De Capitani di Vimercati, S., and P. Samarati, "Location Privacy Protection through Obfuscation-Based Techniques", Proceedings of the 21st Annual IFIP WG 11.3 Working Conference on Data and Applications Security, Redondo Beach, CA, USA, July 2007.
[IFIP07] Ardagna、C.、Cremonini、M.、Damiani、E.、De Capitani di Vimercati、S。、およびP. Samarati、「難読化ベースの手法によるロケーションプライバシー保護」、第21回IFIP WG 11.3議事録データとアプリケーションのセキュリティに関するワーキングカンファレンス、レドンドビーチ、米国カリフォルニア州、2007年7月。
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[RFC2392] Levinson、E。、「Content-ID and Message-ID Uniform Resource Locators」、RFC 2392、1998年8月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778] Day、M.、Rosenberg、J。、およびH. Sugano、「A Presence and Instant Messagingのモデル」、RFC 2778、2000年2月。
[RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[RFC3694] Danley、M.、Mulligan、D.、Morris、J。、およびJ. Peterson、「Threat Analysis of the Geopriv Protocol」、RFC 3694、2004年2月。
[RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.
[RFC4079] Peterson、J。、「GEOPRIVロケーションオブジェクトの配布のためのプレゼンスアーキテクチャ」、RFC 4079、2005年7月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、RFC 4119、2005年12月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「Extensible Markup Language（XML）Configuration Access Protocol（XCAP）」、RFC 4825、2007年5月。
[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.
[RFC5025] Rosenberg、J。、「Presence Authorization Rules」、RFC 5025、2007年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
This document is informed by the discussions within the IETF GEOPRIV working group, including discussions at the GEOPRIV interim meeting in Washington, D.C., in 2003.
This document is informed by the discussions within the IETF GEOPRIV working group, including discussions at the GEOPRIV interim meeting in Washington, D.C., in 2003.
We particularly want to thank Allison Mankin <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon Peterson <jon.peterson@neustar.biz> for their help in improving the quality of this document.
Allison Mankin <mankin@psg.com>、Randall Gellens <rg+ietf@qualcomm.com>、Andrew Newton <anewton@ecotroph.net>、Ted Hardie <hardie@qualcomm.com>、およびJon Petersonに特に感謝します<jon.peterson@neustar.biz>は、このドキュメントの品質向上にご協力いただきました。
We would like to thank Christian Guenther for his help with an earlier version of this document. Furthermore, we would like to thank Johnny Vrancken for his document reviews in September 2006, December 2006 and January 2007. James Winterbottom provided a detailed review in November 2006. Richard Barnes gave a detailed review in February 2008.
このドキュメントの以前のバージョンに対する彼の助けに感謝して、Christian Guentherに感謝します。さらに、2006年9月、2006年12月、2007年1月のドキュメントレビューについて、Jonny Vranckenに感謝します。JamesWinterbottomが2006年11月に詳細なレビューを提供しました。RichardBarnesが2008年2月に詳細なレビューを行いました。
This document uses text from "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO" [GEO-SHAPE], authored by Martin Thomson.
このドキュメントでは、Martin Thomsonによって作成された「PIDF-LOにおける不確実性の表現のための測地図形」[GEO-SHAPE]のテキストを使用します。
We would like to thank Matt Lepinski and Richard Barnes for their comments regarding the geodetic location transformation procedure. Richard provided us with a detailed text proposal.
測地位置変換手順に関するコメントを提供してくれたMatt LepinskiとRichard Barnesに感謝します。リチャードは詳細なテキストの提案を提供してくれました。
Robert Sparks, and Warren Kumari deserve thanks for their input on the location obfuscation discussion. Robert implemented various versions of the algorithm in the graphical language "Processing" and thereby helped us tremendously to understand problems with the previously illustrated algorithm.
ロバート・スパークスとウォーレン・クマリは、ロケーション難読化の議論についての彼らの意見に感謝するに値する。 Robertは、アルゴリズムのさまざまなバージョンをグラフィカル言語「Processing」で実装し、それにより、以前に示したアルゴリズムの問題を非常に理解するのに役立ちました。
We would like to thank Dan Romascanu, Yoshiko Chong, and Jari Urpalainen for their last call comments.
Dan Romascanu、Yoshiko Chong、Jari Urpalainenの最後の電話コメントに感謝します。
Finally, we would like to thank the following individuals for their feedback as part of the IESG, GenArt, and SecDir review: Jari Arkko, Lisa Dusseault, Eric Gray, Sam Hartman, Russ Housley, Cullen Jennings, Chris Newman, Jon Peterson, Tim Polk, Carl Reed, and Brian Rosen.
最後に、IESG、GenArt、およびSecDirのレビューの一部としてフィードバックを提供してくれた次の個人に感謝します。JariArkko、Lisa Dusseault、Eric Grey、Sam Hartman、Russ Housley、Cullen Jennings、Chris Newman、Jon Peterson、Timポーク、カールリード、ブライアンローゼン。
Although John Morris is currently employed by the U.S. Government, he participated in the development of this document in his personal capacity, and the views expressed in the document may not reflect those of his employer.
ジョンモリスは現在米国政府に雇用されていますが、この文書の作成には個人的に参加しており、文書に記載されている見解は彼の雇用主の見解を反映していない場合があります。
This section provides an informal description for the algorithm described in 6.5.2 and 7.5 as pseudocode. In addition to the algorithm, it randomly chooses among equidistant landmarks based on the previous location.
このセクションでは、6.5.2および7.5で擬似コードとして説明されているアルゴリズムの非公式な説明を提供します。アルゴリズムに加えて、以前の位置に基づいて等距離のランドマークからランダムに選択します。
Constants
定数
P = sqrt(3)/6 // approx 0.2887
q = 1 - p // approx 0.7113
Parameters
パラメーター
prob: real // prob is a parameter in the range
// 0.5 <= prob <=1
// recommended is a value for prob between 0.7 and 0.9
// the default of prob is 0.8
Inputs
入力
M = (m,n) : real * real
// M is a pair of reals: m and n
// m is the longitude and n the latitude,
// respectively, of the measured location
// The values are given as real numbers, in the
// range: -180 < m <= 180; -90 < n < 90
// minus values for longitude m correspond to "West"
// minus values for latitude n correspond to "South"
radius : integer // the 'radius' or uncertainty,
// measured in meters
prev-M = (prev-m1, prev-n1): real * real
// the *previously* provided location, if available
// prev-m1 is the longitude and
// prev-n1 the latitude, respectively
o : real
o ：リアル
// this is the reference latitude for the geodesic projection
// The value of 'o' is chosen according to the table below.
// The area you want to project MUST be included in
// between a minimal latitude and a maximal latitude
// given by the two first columns of the table.
// (Otherwise the transformation is not available).
// +------+------+--------------------------+-------+
// | min | max | | |
// | lat | lat | Examples | o |
// +------+------+--------------------------+-------+
// | | | Tropics and subtropics | |
// | -45 | 45 | Africa | 0 |
// | | | Australia | |
// +------+------+--------------------------+-------+
// | | | Continental US | |
// | 25 | 50 | Mediterranean | 25 |
// | | | most of China | |
// +------+------+--------------------------+-------+
// | | | | |
// | 35 | 55 | Southern and Central | 35 |
// | | | Europe | |
// +------+------+--------------------------+-------+
// | | | | |
// | 45 | 60 | Central and Northern | 45 |
// | | | Europe | |
// +------+------+--------------------------+-------+
// | | | | |
// | 55 | 65 | most of Scandinavia | 55 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | | |
// | 60 | 70 | | 60 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | most of | |
// | -50 | -25 | Chile and Argentina | -50 |
// | | | New Zealand | |
// +------+------+--------------------------+-------+
// | | | | |
// | -35 | -55 | | -35 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | | |
// | -45 | -60 | | -45 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | | |
// | -55 | -65 | | -55 |
// | | | | |
// +------+------+--------------------------+-------+
// | | | | |
// | -60 | -70 | | -60 |
// | | | | |
// +------+------+--------------------------+-------+
Outputs
Outputs
M1 = (m1,n1) : real * real // longitude and latitude,
// respectively, of the provided location
Local Variables
ローカル変数
d, d1, d2, l, r, b, t, x, y: real
SW, SE, NW, NE: real * real
// pairs of real numbers, interpreted as coordinates
// longitude and latitude, respectively
temp : Integer[1..8]
temp：整数[1..8]
Function
choose(Ma, Mb: real * real): real * real;
// This function chooses either Ma or Mb
// depending on the parameter 'prob'
// and on prev-M1, the previous value of M1:
// If prev-M1 == Ma choose Ma with probability 'prob'
// If prev-M1 == Mb choose Mb with probability 'prob'
// Else choose Ma or Mb with probability 1/2
Begin
rand:= Random[0,1];
// a real random number between 0 and 1
If prev-M1 == Ma Then
If rand < prob Then choose := Ma;
Else choose := Mb; EndIf
Elseif prev-M1 == Mb Then
If rand < prob Then choose := Mb;
Else choose := Ma; EndIf
Else
If rand < 0.5 Then choose := Ma;
Else choose := Mb; EndIf
End // Function choose
Main // main procedure
Begin
d := radius/1000; // uncertainty, measured in km
d1:= (d * 180) / (pi*M*cos(o));
d2:= d / 110.6;
l := d1*floor(m/d1)
// "floor" returns the largest integer
// smaller or equal to a floating point number
r := l+d1;
b := o+d2*floor(n-o/d2);
t := b+d2;
x := (m-l)/(r-l);
y := (n-b)/(t-b);
SW := (l,b);
SE := (r,b);
NW := (l,t);
NE := (r,t);
If x < p and y < p Then M1 := SW;
Elseif x < p and q <= y Then M1 := NW;
Elseif q <= x and y < p Then M1 := SE;
Elseif q <= x and q <= y Then M1 := NE;
Elseif p <= x and x < q and y < x and y < 1-x
Then M1 := choose(SW,SE);
Elseif p <= y and y < q and x <= y and y < 1-x
Then M1 := choose(SW,NW);
Elseif p <= y and y < q and y < x and 1-x <= y
Then M1 := choose(SE,NE);
Elseif p <= x and x < q and x <= y and 1-x <= y
Then M1 := choose(NW,NE);
Endif
End // Main
End // Main
Authors' Addresses
Authors' Addresses
Henning Schulzrinne (editor) Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
ヘニングシュルズリンネ（編集者）コロンビア大学コンピュータサイエンス学科450コンピュータサイエンスビルディングニューヨーク、ニューヨーク10027アメリカ
Phone: +1 212-939-7042
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Hannes Tschofenig (editor) 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
Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Jorge R.Cuellar Siemens Otto-Hahn-Ring 6ミュンヘンバイエルン自由州ドイツ
EMail: Jorge.Cuellar@siemens.com
James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームスポークシスコ2200東部大統領ジョージブッシュターンパイクリチャードソン、テキサス州75082米国
Phone: +1 817-271-3552
EMail: jmpolk@cisco.com
John B. Morris, Jr.
ジョン・B・モリス・ジュニア
EMail: ietf@jmorris.org Martin Thomson Microsoft 3210 Porter Drive Palo Alto, CA 94304 USA
メール：ietf@jmorris.org Martin Thomson Microsoft 3210 Porter Drive Palo Alto、CA 94304 USA
Phone: +1 650-353-1925
EMail: martin.thomson@gmail.com