[要約] RFC 4119は、プレゼンスベースのGEOPRIV位置オブジェクトのフォーマットに関する規格です。このRFCの目的は、位置情報のプライバシー保護とセキュリティを確保しながら、リアルタイムの位置情報共有を可能にすることです。
Network Working Group J. Peterson
Request for Comments: 4119 NeuStar
Category: Standards Track December 2005
A Presence-based GEOPRIV Location Object Format
存在ベースのGeoprivロケーションオブジェクト形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties.
このドキュメントでは、インターネット上に地理的情報を伝えるためのオブジェクト形式について説明します。この位置オブジェクトは、プライバシーに敏感な存在情報を通信するために設計され、同様のプロパティを持つ存在情報データ形式（PIDF）を拡張します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Location Object Format ..........................................4
2.1. Baseline PIDF Usage ........................................4
2.2. Extensions to PIDF for Location and Usage Rules ............5
2.2.1. 'location-info' Element .............................5
2.2.2. 'usage-rules' Element ...............................7
2.2.3. 'method' Element ....................................9
2.2.4. 'provided-by' Element ...............................9
2.2.5. Schema Definitions .................................10
2.3. Example Location Objects ..................................14
3. Carrying PIDF in a Using Protocol ..............................15
4. Securing PIDF ..................................................15
5. Security Considerations ........................................17
6. IANA Considerations ............................................17
6.1. 'method' Tokens ...........................................17
6.2. 'provided-by' Elements ....................................18
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10 .....................18
7. Acknowledgements ...............................................19
A. Appendix: NENA Provided-by Schema ..............................20
A.1. dataProvider XML Schema ...................................21
Normative References ..............................................22
Informative References ............................................22
Geographical location information describes a physical position in the world that may correspond to the past, present, or future location of a person, event, or device. Numerous applications used in the Internet today benefit from sharing location information (including mapping/navigation applications, 'friend finders' on cell phones, and so on). However, such applications may disclose the whereabouts of a person in a manner contrary to the user's preferences. Privacy lapses may result from poor protocol security (which permits eavesdroppers to capture location information), inability to articulate or accommodate user preferences, or similar defects common in existing systems. The privacy concerns surrounding the unwanted disclosure of a person's physical location are among the more serious issues that confront users on the Internet.
地理的位置情報は、人、イベント、またはデバイスの過去、現在、または将来の場所に対応する可能性のある世界の物理的位置を説明しています。今日のインターネットで使用されている多数のアプリケーションは、位置情報（マッピング/ナビゲーションアプリケーション、携帯電話の「友人のファインダー」など）を共有することで恩恵を受けます。ただし、このようなアプリケーションは、ユーザーの好みに反して、人の所在を開示する場合があります。プライバシーの失効は、プロトコルのセキュリティが不十分であり（盗聴者が位置情報をキャプチャすることを許可します）、ユーザーの好みを明確にしたり収容したり、既存のシステムで一般的な同様の欠陥に対応したりすることがあります。プライバシーは、人の身体的位置の望ましくない開示を取り巻くことに関係しています。これは、インターネット上のユーザーに直面するより深刻な問題の1つです。
Consequently, a need has been identified to convey geographical location information within an object that includes a user's privacy and disclosure preferences and which is protected by strong cryptographic security. Previous work [13] has observed that this problem bears some resemblance to the general problem of communicating and securing presence information on the Internet. Presence (defined in [12]) provides a real-time communications disposition for a user, and thus has similar requirements for selective distribution and security.
したがって、ユーザーのプライバシーと開示の好みを含み、強力な暗号セキュリティによって保護されているオブジェクト内で地理的位置情報を伝える必要性が特定されています。以前の研究[13]は、この問題がインターネット上の存在情報を伝えて確保するという一般的な問題にある程度類似していることを観察しています。存在（[12]で定義）は、ユーザーにリアルタイムの通信処分を提供するため、選択的配布とセキュリティに関する同様の要件があります。
Therefore, this document extends the XML-based Presence Information Data Format (PIDF [2]) to allow the encapsulation of location information within a presence document.
したがって、このドキュメントは、XMLベースのプレゼンス情報データ形式（PIDF [2]）を拡張して、存在ドキュメント内の位置情報のカプセル化を許可します。
This document does not invent any format for location information itself. Numerous existing formats based on civic location, geographic coordinates, and the like, have been developed in other standards fora. Instead, this document defines an object that is suitable both for identifying and encapsulating preexisting location information formats, and for providing adequate security and policy controls to regulate the distribution of location information over the Internet.
このドキュメントは、位置情報自体のフォーマットを発明しません。市民の場所、地理的座標などに基づいた多数の既存の形式は、他の基準で開発されています。代わりに、このドキュメントは、既存の位置情報形式の識別とカプセルの両方に適したオブジェクトを定義します。
The location object described in this document can be used independently of any 'using protocol', as the term is defined in the GEOPRIV requirements [10]. It is considered an advantage of this proposal that existing presence protocols (such as [14]) would natively accommodate the location object format defined in this document, and be capable of composing location information with other presence information, because this location object is an extension of PIDF. However, the usage of this location object format is not limited to presence-using protocols-- any protocol that can carry XML or MIME types can carry PIDF.
このドキュメントで説明されているロケーションオブジェクトは、GEOPRIV要件で定義されているため、「プロトコルを使用する」とは独立して使用できます[10]。この提案の利点は、既存の存在プロトコル（[14]など）がこのドキュメントで定義されているロケーションオブジェクト形式にネイティブに対応し、他の存在情報と位置情報を作成できるという利点と考えられています。PIDFの。ただし、このロケーションオブジェクト形式の使用は、存在するプロトコルに限定されません。これは、XMLまたはMIMEタイプを運ぶことができるプロトコルではPIDFを運ぶことができます。
Some of the requirements in [10] and [11] concern data collection and usage policies associated with location objects. This document provides only the minimum markup necessary for a user to express the necessary privacy preferences as specified by the GEOPRIV requirements (the three basic elements in [11]). However, this document does not demonstrate how a full XML-based ruleset, accommodating the needs of Location Servers, could be embedded in PIDF. It is assumed that other protocols (such as HTTP) will be used to move rules between Rule Holders and Location Servers, and that full rulesets will be defined in a separate document.
[10]および[11]の要件の一部は、ロケーションオブジェクトに関連付けられたデータ収集と使用ポリシーに関するものです。このドキュメントは、ユーザーがGEOPRIV要件（[11]の3つの基本要素）で指定されているように、必要なプライバシー設定を表現するために必要な最小マークアップのみを提供します。ただし、このドキュメントでは、ロケーションサーバーのニーズに対応する完全なXMLベースのルールセットがPIDFにどのように埋め込まれるかを示すものではありません。他のプロトコル（HTTPなど）を使用して、ルールホルダーとロケーションサーバー間のルールを移動するために使用され、完全なルールセットは別のドキュメントで定義されると想定されています。
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 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[1]に記載されているとおりに解釈される。
The GEOPRIV requirements [10] (or REQ for short) specify the need for a name for the person, place or thing that location information describes (REQ 2.1). PIDF has such an identifier already: every PIDF document has an "entity" attribute of the 'presence' element that signifies the URI of the entity whose presence the document describes. Consequently, if location information is contained in a PIDF document, the URI in the "entity" attribute of the 'presence' element indicates the target of that location information (the 'presentity'). The URI in the "entity" attribute generally uses the "pres" URI scheme defined in [3]. Such URIs can serve as unlinkable pseudonyms (per REQ 12).
GEOPRIV要件[10]（または略してReq）は、位置情報が説明する人、場所、または物の名前の必要性を指定します（Req 2.1）。PIDFには既にそのような識別子があります。すべてのPIDFドキュメントには、ドキュメントが説明する存在感のあるエンティティのURIを意味する「存在」要素の「エンティティ」属性があります。その結果、位置情報がPIDFドキュメントに含まれている場合、「存在」要素の「エンティティ」属性のURIは、その位置情報（「プレゼンティ」）のターゲットを示します。「エンティティ」属性のURIは、一般に[3]で定義されている「Pres」URIスキームを使用します。このようなurisは、リンクできない仮名として機能する可能性があります（Req 12ごと）。
PIDF optionally contains a 'contact' element that provides a URI where the presentity can be reached by some means of communication. Usually, the URI scheme in the value of the 'contact' element gives some sense of how the presentity can be reached; if it uses the SIP URI scheme, for example, SIP can be used, and so on. Location information can be provided without any associated means of communication. Thus, the 'contact' element may or may not be present, as desired by the creator of the PIDF document.
PIDFには、オプションで、何らかのコミュニケーション手段によって提示に到達できるURIを提供する「連絡先」要素が含まれています。通常、「接触」要素の値におけるURIスキームは、プレゼンテーションにどのように到達できるかについての感覚を与えます。たとえば、SIP URIスキームを使用する場合、SIPを使用できます。位置情報は、関連する通信手段なしで提供できます。したがって、PIDFドキュメントの作成者が望むように、「連絡先」要素が存在する場合と存在しない場合があります。
PIDF optionally contains a 'timestamp' element that designates the time at which the PIDF document was created. This element corresponds to REQ 2.7a.
PIDFには、オプションで、PIDFドキュメントが作成された時間を指定する「タイムスタンプ」要素が含まれています。この要素は、Req 2.7aに対応しています。
PIDF contains a 'status' element, which is mandatory. 'status' contains an optional child element, 'basic', that describes the presentity's communications disposition (in very broad terms: either OPEN or CLOSED). For the purposes of this document, it is not necessary for 'basic' status to be included. If, however, communications disposition is included in a PIDF document above and beyond geolocation, then 'basic' status may appear in a PIDF document that uses these extensions.
PIDFには「ステータス」要素が含まれています。これには必須です。「ステータス」には、オプションの子要素「Basic」が含まれています。これは、プレゼンテーションのコミュニケーションの処分を説明しています（非常に広い用語：オープンまたはクローズ）。このドキュメントの目的のために、「基本」ステータスを含める必要はありません。ただし、コミュニケーションの処分が地理的上記のPIDFドキュメントに含まれている場合、これらの拡張機能を使用するPIDFドキュメントに「基本」ステータスが表示される場合があります。
PIDF also contains a 'tuple' umbrella element, which holds an "id" element used to uniquely identify a segment of presence information so that changes to this information can be tracked over time (as multiple notifications of presence are received). 'timestamp', 'status', and 'contact' are composed under 'tuple'.
PIDFには、「タプル」傘要素も含まれています。この要素は、存在情報のセグメントを一意に識別するために使用される「ID」要素を保持して、この情報の変更を時間の経過とともに追跡できるようにします（存在の複数の通知が受信されるため）。「タイムスタンプ」、「ステータス」、および「連絡先」は「タプル」の下に構成されています。
This XML Schema extends the 'status' element of PIDF with a complex element called 'geopriv'. There are two major subelements that are encapsulated within geopriv: one for location information, and one for usage rules. Both of these subelements are mandatory, and are described in subsequent sections. By composing these two subelements under 'geopriv', the usage rules are clearly and explicitly associated with the location information.
このXMLスキーマは、「Geopriv」と呼ばれる複雑な要素を持つPIDFの「ステータス」要素を拡張します。GeoPriv内にカプセル化された2つの主要なサブエレメントがあります。1つは位置情報用、もう1つは使用規則です。これらのサブエレメントは両方とも必須であり、後続のセクションで説明されています。これらの2つのサブエレメントを「Geopriv」の下で作成することにより、使用規則は位置情報に明確かつ明示的に関連付けられています。
For extensibility (see REQ 1.4), the schema allows any other subelements to appear under the 'geopriv' element. Two other optional subelements are included in this document: one that indicates the method by which geographical location was determined, and one that allows an explicit designation of the entity that provided the information.
拡張性（Req 1.4を参照）の場合、スキーマは他のサブエレメントを「geopriv」要素の下に表示することができます。このドキュメントには、他の2つのオプションのサブエレメントが含まれています。1つは地理的位置が決定された方法を示すものと、情報を提供したエンティティの明示的な指定を可能にするものです。
Each 'geopriv' element MUST contain one 'location-info' element. A 'location-info' element consists of one or more chunks of location information (per REQ 2.5). The format of the location information (REQ 2.6) is identified by the imported XML Schema, which describes the namespace in question. All PIDF documents that contain a 'geopriv' element MUST contain one or more import directives indicating the XML Schema(s) that are used for geographic location formats.
各「geopriv」要素には、1つの「location-info」要素が含まれている必要があります。「ロケーションインフォ」要素は、1つ以上の位置情報（REQ 2.5ごと）で構成されています。位置情報（REQ 2.6）の形式は、問題の名前空間を記述するインポートされたXMLスキーマによって識別されます。「GeoPriv」要素を含むすべてのPIDFドキュメントには、地理的位置形式に使用されるXMLスキーマを示す1つ以上のインポートディレクティブを含める必要があります。
In order to ensure interoperability of GEOPRIV implementations, it is necessary to select a baseline location format that all compliant implementations support (see REQ 3.1). Because it satisfies REQ 2.5.1, this document works from the assumption that Geography Markup Language (GML) 3.0 [15] shall be this mandatory format (a MUST implement for all PIDF implementations supporting the 'geopriv' element).
GEOPRIVの実装の相互運用性を確保するために、すべての準拠の実装がサポートするベースラインロケーション形式を選択する必要があります（REQ 3.1を参照）。Req 2.5.1を満たすため、このドキュメントは、地理マークアップ言語（GML）3.0 [15]がこの必須形式（「Geopriv」要素をサポートするすべてのPIDF実装の必須実装）であるという仮定から機能します。
GML is an extraordinarily thorough and versatile system for modeling all manner of geographic object types, topologies, metadata, coordinate reference systems, and units of measurement. The simplest package for GML supporting location
GMLは、あらゆる種類の地理的オブジェクトタイプ、トポロジー、メタデータ、調整参照システム、および測定単位をモデル化するための非常に徹底的で汎用性の高いシステムです。GMLサポートロケーション用の最もシンプルなパッケージ
information is the 'feature.xsd' schema. Although 'feature.xsd' can express complicated geographical concepts, it requires very little markup to provide basic coordinate points for the most commonly used cases. Various format descriptions (including latitude/longitude based location information) are supported by Feature (see section 7.4.1.4 of [15] for examples), which resides here:
情報は「feature.xsd」スキーマです。「feature.xsd」は複雑な地理的概念を表現できますが、最も一般的に使用されるケースに基本的な座標ポイントを提供するために、マークアップはほとんど必要ありません。さまざまな形式の説明（緯度/経度ベースの位置情報を含む）は、機能によってサポートされています（例については[15]のセクション7.4.1.4を参照）。
urn:opengis:specification:gml:schema-xsd:feature:v3.0
Note that by importing the Feature schema, necessary GML baseline schemas are transitively imported.
特徴スキーマをインポートすることにより、必要なGMLベースラインスキーマがトランザティブにインポートされることに注意してください。
Complex features (such as modeling topologies and polygons, directions and vectors, temporal indications of the time for which a particular location is valid for a target) are also available in GML, but require importing additional schemas. For the purposes of baseline interoperability as defined by this document, only support for the 'feature.xsd' GML schema is REQUIRED.
複雑な機能（トポロジーとポリゴンのモデリング、方向とベクトル、特定の場所がターゲットに有効な時間の時間的適応）もGMLで利用可能ですが、追加のスキーマをインポートする必要があります。このドキュメントで定義されているベースラインの相互運用性の目的のために、「feature.xsd」GMLスキーマのサポートのみが必要です。
Implementations MAY support the civic location format (civicLoc) defined in Section 2.2.5. civicLoc provides the following elements:
実装は、セクション2.2.5で定義されているシビックロケーション形式（CivicLoc）をサポートする場合があります。Civiclocは次の要素を提供します。
+----------------------+----------------------+---------------------+
| Label | Description | Example |
+----------------------+----------------------+---------------------+
| country | The country is | US |
| | identified by the | |
| | two-letter ISO 3166 | |
| | code. | |
| | | |
| A1 | national | New York |
| | subdivisions (state, | |
| | region, province, | |
| | prefecture) | |
| | | |
| A2 | county, parish, gun | King's County |
| | (JP), district (IN) | |
| | | |
| A3 | city, township, shi | New York |
| | (JP) | |
| | | |
| A4 | city division, | Manhattan |
| | borough, city | |
| | district, ward, chou | |
| | (JP) | |
| | | |
| A5 | neighborhood, block | Morningside Heights |
| | | |
| A6 | street | Broadway |
| | | |
| PRD | Leading street | N, W |
| | direction | |
| | | |
| POD | Trailing street | SW |
| | suffix | |
| | | |
| STS | Street suffix | Avenue, Platz, |
| | | Street |
| | | |
| HNO | House number, | 123 |
| | numeric part only. | |
| | | |
| HNS | House number suffix | A, 1/2 |
| | | |
| LMK | Landmark or vanity | Low Library |
| | address | |
| | | |
| LOC | Additional location | Room 543 |
| | information | |
| | | |
| FLR | Floor | 5 |
| | | |
| NAM | Name (residence, | Joe's Barbershop |
| | business or office | |
| | occupant) | |
| | | |
| PC | Postal code | 10027-0401 |
+----------------------+----------------------+---------------------+
Either the GML 3.0 geographical information format element, or the location format element ('civicLoc') defined in this document, MAY appear in a 'location-info' element. Both MAY also be used in the same 'location-info' element. In summary, the feature.xsd schema of GML 3.0 MUST be supported by implementations compliant with this specification, and the civicLoc format MAY be supported by implementations compliant with this specification.
このドキュメントで定義されているGML 3.0地理情報形式要素、または「civicloc」（ 'civicloc'）のいずれかが、「location-info」要素に表示される場合があります。どちらも同じ「ロケーションインフォ」要素でも使用できます。要約すると、GML 3.0のfeature.xsdスキーマは、この仕様に準拠した実装によってサポートされる必要があり、Civicloc形式は、この仕様に準拠した実装によってサポートされる場合があります。
At the time this document was written, the policy requirements for GEOPRIV objects were not definitively completed. However, the 'usage-rules' element exists to satisfy REQ 2.8 and the requirements of the GEOPRIV policy requirements [11] document. Each 'geopriv' element MUST contain one 'usage-rules' element, even if the Rule
このドキュメントが書かれた時点で、GEOPRIVオブジェクトのポリシー要件は明確に完了しませんでした。ただし、REQ 2.8とGeoPRIVポリシー要件[11]文書の要件を満たすために、「使用率」要素が存在します。各「geopriv」要素は、たとえルールがあっても、1つの「使用法」要素を含める必要があります
Maker has requested that all subelements be given their default values.
Makerは、すべてのサブエレメントにデフォルト値を与えることを要求しました。
Following the policy requirements document (Section 3.1), there are three fields that need to be expressible in Location Objects throughout their lifecycle (from Generator to Recipient): one field that limits retransmission, one that limits retention, and one that contains a reference to external rulesets. Those three fields are instantiated here by the first three elements. The fourth element provides a generic space for human-readable policy directives. Any of these fields MAY be present in a Location Object 'usage-rules' element; none are required to be.
ポリシー要件文書（セクション3.1）に従って、ライフサイクル全体（ジェネレーターから受信者まで）全体の位置オブジェクトで表現できる必要がある3つのフィールドがあります。再送信を制限するフィールド、保持を制限する1つ、および外部ルールセット。これらの3つのフィールドは、最初の3つの要素によってここにインスタンス化されています。4番目の要素は、人間が読みやすいポリシー指令のための一般的な空間を提供します。これらのフィールドのいずれかは、ロケーションオブジェクトの「使用量」要素に存在する場合があります。必要はありません。
'retransmission-allowed': When the value of this element is 'no', the Recipient of this Location Object is not permitted to share the enclosed Location Information, or the object as a whole, with other parties. When the value of this element is 'yes', distributing this Location is permitted (barring an existing out-of-band agreement or obligation to the contrary). By default, the value MUST be assumed to be 'no'. Implementations MUST include this field, with a value of 'no', if the Rule Maker specifies no preference.
「再送信」：この要素の値が「いいえ」の場合、この位置オブジェクトの受信者は、囲まれた位置情報、または全体としてオブジェクトを他の当事者と共有することは許可されていません。この要素の値が「はい」の場合、この場所の分配は許可されています（既存の帯域外契約または反対の義務を除いて）。デフォルトでは、値は「いいえ」であると想定する必要があります。ルールメーカーが好みを指定していない場合、実装には「いいえ」の値があるこのフィールドを含める必要があります。
'retention-expires': This field specifies an absolute date at which time the Recipient is no longer permitted to possess the location information and its encapsulating Location Object; both may be retained only until the time specified by this field. By default, the value MUST be assumed to be twenty-four hours from the 'timestamp' element in the PIDF document, if present; if the 'timestamp' element is also not present, then the value MUST be assumed to be twenty-four hours from the time at which the Location Object is received by the Location Recipient. If the value in the 'retention-expires' element has already passed when the Location Recipient receives the Location Object, the Recipient MUST discard the Location Object immediately.
「保持 - expires」：このフィールドは、受信者が位置情報とそのカプセル化位置オブジェクトを所有することを許可されなくなった絶対日付を指定します。どちらも、このフィールドで指定される時間までのみ保持される場合があります。デフォルトでは、PIDFドキュメントの「タイムスタンプ」要素から24時間であると想定される必要があります。「タイムスタンプ」要素も存在しない場合、位置オブジェクトが場所の受信者によって受信される時間から24時間であると想定する必要があります。「保持」要素の値が、場所の受信者が位置オブジェクトを受信したときに既に渡されている場合、受信者はすぐにロケーションオブジェクトを破棄する必要があります。
'ruleset-reference': This field contains a URI that indicates where a fuller ruleset of policies, related to this object, can be found. This URI SHOULD use the HTTPS URI scheme; and if it does, the server that holds these rules MUST authenticate any attempt to access these rules. Usage rules themselves may divulge private information about a Target or Rule Maker. The URI MAY, alternatively, use the CID URI scheme [7], in which case it MUST denote a MIME body carried with the Location Object by the using protocol. Rulesets carried as MIME bodies SHOULD be encrypted and signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored by Location Servers or Location Recipients. Note that in order to avoid network lookups that result in an authorization failure, creators of Location Objects MAY put HTTPS-based ruleset-references into an encrypted external MIME body referenced by a CID; in this way, recipients of the Location Object that are unable to decrypt the external MIME body will not learn the HTTPS URI unless they are able to decrypt the MIME body.
'Ruleset-reference'：このフィールドには、このオブジェクトに関連するポリシーの完全なルールセットがどこにあるかを示すURIが含まれています。このURIは、HTTPS URIスキームを使用する必要があります。もしそうなら、これらのルールを保持するサーバーは、これらのルールにアクセスしようとする試みを認証する必要があります。使用ルール自体は、ターゲットまたはルールメーカーに関する個人情報を漏らします。または、URIは、CID URIスキーム[7]を使用する場合があります。この場合、プロトコルを使用して位置オブジェクトに運ばれるMIMEボディを示す必要があります。Mime Bodyとして運ばれるルールセットは、ルールメーカーによって暗号化され、署名されるべきです。署名されていないルールセットは、ロケーションサーバーやロケーション受信者によって尊重されるべきではありません。認証障害をもたらすネットワーク検索を回避するために、ロケーションオブジェクトの作成者は、CIDが参照される暗号化された外部MIMEボディにHTTPSベースのルールセット参照を配置する可能性があることに注意してください。このようにして、外部マイムボディを復号化できない位置オブジェクトの受信者は、マイムボディを復号化できない限り、HTTPS URIを学習しません。
'note-well': This field contains a block of text containing further generic privacy directives. These directives are intended to be human-readable only, not to be processed by any automaton.
'Note-Well'：このフィールドには、さらに一般的なプライバシーディレクティブを含むテキストのブロックが含まれています。これらの指令は、オートマトンによって処理されることはありません。
The optional 'method' element describes the way that the location information was derived or discovered. An example of this element (for a geographical position system) is:
オプションの「メソッド」要素は、位置情報が導出または発見された方法を説明します。この要素の例（地理的位置システムの場合）は次のとおりです。
<method>gps</method>
The possible values of the 'method' element are enumerated within an IANA registry. Implementations MUST limit the use of this method to the values shepherded by IANA. This document pre-populates the IANA registry with seven possible values; see Section 6.1 for more information.
「メソッド」要素の可能な値は、IANAレジストリ内に列挙されます。実装は、この方法の使用をIANAによって羊飼いの値に制限する必要があります。このドキュメントは、7つの可能な値でIANAレジストリを事前に定住させます。詳細については、セクション6.1を参照してください。
The 'method' element is useful, for example, when multiple sources are reporting location information for a given user, and some means of determining location might be considered more authoritative than others (i.e., a dynamic, real-time position system versus static provisioning associated with a target device). However, note that inclusion of 'method' might reveal sensitive information when the generator is providing intentionally coarsened location information. For example, when a LO is transmitted with 'DHCP' as the 'method', but the location information indicates only the city in which the generator is located, the sender has good justification to suspect that some location information is being withheld.
たとえば、「メソッド」要素は、特定のユーザーの位置情報を複数のソースが報告している場合に有用です。場所を決定する方法は、他のユーザーよりも権威あると見なされる場合があります（つまり、動的、リアルタイム位置システムと静的プロビジョニングターゲットデバイスに関連付けられています）。ただし、ジェネレーターが意図的に粗い位置情報を提供している場合、「メソッド」を含めると機密情報が明らかになる可能性があることに注意してください。たとえば、LOが「メソッド」として「DHCP」で送信されますが、位置情報はジェネレーターが配置されている都市のみを示している場合、送信者はいくつかの位置情報が差し控えられていると疑うために良い正当性を持っています。
The optional 'provided-by' element describes the entity or organization that supplied this location information (beyond the domain information that can be inferred from a signing certificate). An example of this element (for a made-up game system) might be:
オプションの「提供された」要素は、この位置情報を提供したエンティティまたは組織について説明します（署名証明書から推測できるドメイン情報を超えて）。この要素の例（構成されたゲームシステムの場合）は次のとおりです。
<provided-by>
<test:game>
West5
</test:game>
</provided-by>
Values for the 'provided-by' element MUST be IANA-registered XML namespaces; see Section 6.2 for more information.
「提供された」要素の値は、IANA登録XMLネームスペースでなければなりません。詳細については、セクション6.2を参照してください。
The 'provided-by' element is not intended for use by most entities, but rather to meet special requirements for which overhead (IANA registration, location object size) and potential location information leakage are acceptable choices.
「提供された」要素は、ほとんどのエンティティが使用することではなく、オーバーヘッド（IANA登録、位置オブジェクトサイズ）および潜在的な位置情報漏れが許容可能な選択肢である特別な要件を満たすことを目的としています。
In general cases, the entity that supplied location information is communicated by the subjectAltName of the certificate with which the location object is signed; thus, this element is unnecessary. 'Provided-by' is meaningful in particular cases when the creator of a location object wants to designate a particular system or party within a complex administrative domain, including situations envisioned for providing emergency services in a diverse national context. It might assist, for example, the recipient of a malformed or misleading location object in identifying the particular system that malfunctioned.
一般的に、位置情報を提供したエンティティは、位置オブジェクトが署名されている証明書の件名によって伝えられます。したがって、この要素は不要です。「提供された」は、場所オブジェクトの作成者が、多様な国家的文脈で緊急サービスを提供するために想定されている状況を含む、複雑な管理領域内で特定のシステムまたは当事者を指定したい場合に意味があります。たとえば、奇形または誤解を招く場所のオブジェクトの受信者が、誤動作した特定のシステムを識別するのに役立ちます。
Users should be aware that this information can inadvertently provide additional information to the receiver, increasing the effective resolution of the geospatial or civic information, or even revealing some location information, when it was meant to be entirely protected. Consider if there were circumstances that influenced Columbia University to elect to register and use the provided-by element. If an example LO includes only state-level information, then including the fact that the location information was provided by Columbia University provides a strong indication that the Target is actually located in a four-block area in Manhattan. Accordingly, this element should be used only when organizational functions strongly would depend on it. In all but such usages, the subjectAltName of the certificate will suffice, and 'provided-by' SHOULD NOT be used.
ユーザーは、この情報が誤って追加情報を受信機に提供したり、地理空間情報または市民情報の効果的な解決を増やしたり、完全に保護されることを意図している場合にいくつかの位置情報を明らかにすることさえできることに注意する必要があります。コロンビア大学に影響を与えた状況が、提供された要素を登録して使用することを選択するようになったかどうかを検討してください。例にloが州レベルの情報のみが含まれている場合、コロンビア大学によって位置情報が提供されたという事実を含めて、ターゲットが実際にマンハッタンの4ブロックエリアにあることを強く示します。したがって、この要素は、組織機能が強く依存する場合にのみ使用する必要があります。このような使用法を除くすべての場合、証明書のsumberaltnameで十分であり、「提供された」を使用しないでください。
Note that the XML namespace [4] for this extension to PIDF contains a version number 1.0 (as per REQ 2.10).
PIDFへのこの拡張機能のXMLネームスペース[4]には、バージョン番号1.0（REQ 2.10に従って）が含まれていることに注意してください。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace=
"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" />
<!-- 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"/>
<xs:element name="geopriv" type="tns:geopriv"/>
<xs:complexType name="geopriv">
<xs:sequence>
<xs:element name="location-info" type="tns:locInfoType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="usage-rules" type="gbp:locPolicyType"
minOccurs="1" maxOccurs="1"/>
<xs:element name="method" type="tns:locMethod"
minOccurs="0" maxOccurs="1"/>
<xs:element name="provided-by" type="tns:locProvidedBy"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locInfoType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locMethod">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="locProvidedBy">
<xs:sequence>
<xs:any namespace="##other" processContents="skip"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
The 'geopriv10' schema imports, for the 'usage-rules' element, the following policy schema. This schema has been broken out from the basic geolocation object in order to allow for its reuse. The semantics associated with these elements, described in Section 2.2.2, apply only to the use of these elements to define policy for geolocation objects; any other use of 'usage-rules' must characterize its own semantics for all 'usage-rules' subelements.
「geopriv10」スキーマは、「使用率」要素のために、次のポリシースキーマをインポートします。このスキーマは、再利用を可能にするために、基本的なジオロケーションオブジェクトから分割されています。セクション2.2.2で説明されているこれらの要素に関連するセマンティクスは、これらの要素の使用にのみ適用され、ジオロケーションオブジェクトのポリシーを定義します。「使用型」のその他の使用は、すべての「使用法」サブエレメントに対する独自のセマンティクスを特徴付ける必要があります。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- 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"/>
<xs:complexType name="locPolicyType">
<xs:sequence>
<xs:element name="retransmission-allowed" type="xs:boolean"
minOccurs="0" maxOccurs="1"/>
<xs:element name="retention-expiry" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="external-ruleset" type="xs:anyURI"
minOccurs="0" maxOccurs="1"/>
<xs:element name="note-well" type="tns:notewell"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="notewell">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
The following schema is a trivial representation of civic location that MAY be implemented by entities compliant with this specification.
次のスキーマは、この仕様に準拠したエンティティによって実装される可能性のある市民の場所の些細な表現です。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name="civicAddress">
<xs:sequence>
<xs:element name="country" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A1" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A2" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A3" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A4" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A5" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="A6" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PRD" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="POD" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="STS" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="HNO" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="HNS" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="LMK" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="LOC" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="FLR" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="NAM" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:element name="PC" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Note that these examples show PIDF documents without any MIME headers or security applied to them (see Section 4 below).
これらの例は、MIMEヘッダーまたはセキュリティが適用されていないPIDFドキュメントを示していることに注意してください（以下のセクション4を参照）。
The following XML instance document is an example of the use of a simple GML 3.0 markup with a few of the policy directives specified above within a PIDF document. The GPS coordinates given in the 'gml' element are for San Francisco, CA.
次のXMLインスタンスドキュメントは、PIDFドキュメント内で上記で指定されたいくつかのポリシー指令を備えた単純なGML 3.0マークアップの使用の例です。「GML」要素に記載されているGPS座標は、カリフォルニア州サンフランシスコ向けです。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
The following XML instance document is an example of the use of the civicLoc object with a few of the policy directives specified above within a PIDF document.
次のXMLインスタンスドキュメントは、PIDFドキュメント内で上記で指定されたいくつかのポリシー指令を使用したCivicLocオブジェクトの使用の例です。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>New York</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
<cl:LOC>Suite 75</cl:LOC>
<cl:PC>10027-0401</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
A PIDF document is an XML document; therefore, PIDF might be carried in any protocol capable of carrying XML. A MIME type has also been registered for PIDF: 'application/pidf+xml'. PIDF may therefore be carried as a MIME body in protocols that use MIME (such as SMTP, HTTP, or SIP) with an encapsulating set of MIME headers, including a Content-Type of 'application/pidf+xml'.
PIDFドキュメントはXMLドキュメントです。したがって、PIDFは、XMLを運ぶことができるプロトコルで運ばれる可能性があります。MIMEタイプもPIDFに登録されています： 'Application/PIDF XML'。したがって、PIDFは、「アプリケーション/PIDF XML」のコンテンツタイプを含む、MIMEヘッダーのカプセル化セットを使用して、MIME（SMTP、HTTP、SIPなど）を使用するプロトコルのMIMEボディとして運ばれます。
Further specification of the behavior of using protocols (including subscribing to or requesting presence information) is outside the scope of this document.
このドキュメントの範囲外であるプロトコル（存在情報への購読または要求を含む）の使用の動作のさらなる仕様があります。
There are a number of ways in which XML documents can be secured. XML itself supports several ways of partially securing documents, including element-level encryption and digital signature properties.
XMLドキュメントを保護できる方法はいくつかあります。XML自体は、要素レベルの暗号化やデジタル署名プロパティなど、ドキュメントを部分的に保護するいくつかの方法をサポートしています。
For the purposes of this document, only the securing of a PIDF document as a whole, rather than element-by-element security, is considered. None of the requirements [10] suggest that only part of the information in a location object might need to be protected while other parts are unprotected; virtually any such configuration would introduce potentials for privacy leakage. Consequently, the use of MIME-level security is appropriate.
このドキュメントの目的のために、要素ごとのセキュリティではなく、PIDFドキュメント全体を保護することのみが考慮されます。要件[10]は、他の部品が保護されていない間、ロケーションオブジェクトの情報の一部のみを保護する必要があることを示唆していません。事実上、このような構成は、プライバシー漏れの可能性を導入します。その結果、Mimeレベルのセキュリティの使用が適切です。
S/MIME [5] allows security properties (including confidentiality, integrity, and authentication properties) to be applied to the contents of a MIME body. Therefore, all PIDF implementations that support the XML Schema extensions for location information described in this document MUST support S/MIME; in particular, they MUST support the CMS [6] EnvelopedData and SignedData content types, which are used for encryption and digital signatures, respectively. It is believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3, and 14.4.
S/MIME [5]により、セキュリティプロパティ（機密性、整合性、認証プロパティを含む）をMIMEボディの内容に適用できます。したがって、このドキュメントで説明されている位置情報のXMLスキーマ拡張機能をサポートするすべてのPIDF実装は、S/MIMEをサポートする必要があります。特に、暗号化とデジタル署名にそれぞれ使用されるCMS [6] EnvelopedDataおよびSignedDataコンテンツタイプをサポートする必要があります。このメカニズムは、Req 2.10、13、14.1、14.2、14.3、および14.4を満たしていると考えられています。
Additionally, all compliant applications MUST implement the AES encryption algorithm for S/MIME, as specified in [8] (and per REQ 15.1). Of course, implementations MUST also support the baseline encryption and digital signature algorithms described in the S/MIME specification.
さらに、すべての準拠アプリケーションは、[8]（およびREQ 15.1ごと）で指定されているように、S/MIMEのAES暗号化アルゴリズムを実装する必要があります。もちろん、実装は、S/MIME仕様で説明されているベースライン暗号化とデジタル署名アルゴリズムもサポートする必要があります。
S/MIME generally entails the use of X.509 [9] certificates. In order to encrypt a request for a particular destination end-to-end (i.e., to a Location Recipient), the Location Generator must possess credentials (typically an X.509 certificate) that have been issued to the Location Recipient. Implementations of this specification SHOULD support X.509 certificates for S/MIME, and MUST support password-based CMS encryption (see [6]). Any symmetric keying systems SHOULD derive high-entropy content encoding keys (CEKs). When X.509 certificates are used to sign PIDF Location Objects, the subjectAltName of the certificate SHOULD use the "pres" URI scheme.
S/MIMEは通常、X.509 [9]証明書の使用を伴います。特定の宛先エンドツーエンド（つまり、場所の受信者に対する）のリクエストを暗号化するには、ロケーションジェネレーターには、場所の受信者に発行された資格情報（通常はX.509証明書）を所有する必要があります。この仕様の実装は、S/MIMEのX.509証明書をサポートし、パスワードベースのCMS暗号化をサポートする必要があります（[6]を参照）。対称キーリングシステムは、高エントロピーコンテンツをコードするキー（CEKS）を導出する必要があります。X.509証明書を使用してPIDFロケーションオブジェクトに署名する場合、証明書の件名は「Pres」URIスキームを使用する必要があります。
One envisioned deployment model for S/MIME in PIDF documents is the following. Location Servers hold X.509 certificates and share secrets with Location Generators and Location Recipients. When a Generator sends location information to a Server, it can be encrypted with S/MIME (or any lower-layer encryption specific to the using protocol). When a Server forwards location information to a Recipient, location information can be encrypted with password-based CMS encryption. This allows the use of encryption when the Location Recipient does not possess its own X.509 certificate.
PIDFドキュメントのS/MIMEの展開モデルの1つは、次のとおりです。ロケーションサーバーはX.509証明書を保持し、ロケーションジェネレーターとロケーション受信者と秘密を共有します。ジェネレーターが位置情報をサーバーに送信すると、S/MIME（または使用するプロトコルに固有の低層暗号化）で暗号化できます。サーバーが位置情報を受信者に転送すると、位置情報をパスワードベースのCMS暗号化で暗号化できます。これにより、場所の受信者が独自のX.509証明書を所有していない場合、暗号化を使用できます。
S/MIME was designed for end-to-end security between email peers that communicate through multiple servers (i.e mail transfer agents) that do not modify message bodies. There is, however, at least one instance in which Location Servers modify Location Objects: when Location Servers enforce policies on behalf of the Rule Maker. For example, a Rule Maker may specify that Location Information should be coarsened (made less specific) before it is transmitted to particular recipients. If the Location Server were unable to modify a Location Object, because it was encrypted, signed, or both, it would be unable to accomplish this function. Consequently, when a Location Generator wants to allow a Location Server to modify such messages, they MAY encrypt such messages with a key that can be decrypted by the Location Server (the digital signature, of course, can still be created with keying material from the Location Generator's certificate). After modifying the Location Object, the Location
S/MIMEは、メッセージ本文を変更しない複数のサーバー（つまり、メール転送エージェント）を介して通信する電子メールピア間のエンドツーエンドのセキュリティ用に設計されました。ただし、ロケーションサーバーがロケーションオブジェクトを変更する少なくとも1つのインスタンスがあります。ロケーションサーバーがルールメーカーに代わってポリシーを実施する場合。たとえば、ルールメーカーは、特定の受信者に送信される前に、位置情報が粗く（具体的ではない）ことを指定する場合があります。ロケーションサーバーが暗号化、署名、またはその両方であるため、ロケーションオブジェクトを変更できなかった場合、この関数を達成できません。したがって、ロケーションジェネレーターがロケーションサーバーにそのようなメッセージの変更を許可する場合、ロケーションサーバーで復号化できるキーを使用してそのようなメッセージを暗号化することができます（もちろん、デジタル署名は、引き続きです。ロケーションジェネレーターの証明書）。ロケーションオブジェクトを変更した後、場所
Server can re-sign the Object with its own credentials (encrypting it with any keys issued to the Location Recipient, if they are known to the Server).
サーバーは、独自の資格情報でオブジェクトを再署名できます（サーバーに既知の場合は、受信者に発行されたキーでそれを暗号化することができます）。
Note that policies for data collection and usage of location information, in so far as they are carried within a location object, are discussed in Section 2.2.2.
データ収集のポリシーと位置情報の使用に関するポリシーは、それらが位置オブジェクト内で運ばれる限り、セクション2.2.2で説明していることに注意してください。
The threats facing an Internet protocol that carries geolocation information are detailed in [16]. The requirements that were identified in that analysis of the threat model were incorporated into [10], in particular within Section 7.4. This document aims to be compliant with the security requirements derived from those two undertakings, in so far as they apply to the location object itself (as opposed to the using protocol).
地理的情報を運ぶインターネットプロトコルが直面している脅威は[16]に詳述されています。脅威モデルの分析で特定された要件は、特にセクション7.4に[10]に組み込まれました。このドキュメントの目的は、（使用中のプロトコルとは対照的に）ロケーションオブジェクト自体に適用される限り、これら2つの事業から派生したセキュリティ要件に準拠することを目的としています。
Security of the location object defined in this document, including normative requirements for implementations, is discussed in Section 4. This security focuses on end-to-end integrity and confidentiality properties that are applied to a location object for its lifetime via S/MIME.
実装の規範的要件を含むこのドキュメントで定義されているロケーションオブジェクトのセキュリティについては、セクション4で説明します。このセキュリティは、S/MIMEを介してその寿命のためにロケーションオブジェクトに適用されるエンドツーエンドの完全性と機密性のプロパティに焦点を当てています。
Security requirements associated with using protocols (including authentication of subscribers to geographical information, etc.) are outside the scope of this document.
プロトコルの使用に関連するセキュリティ要件（地理情報への加入者の認証など）は、このドキュメントの範囲外です。
This document requests that the IANA create a new registry for 'method' tokens associated with the PIDF-LO object. 'method' tokens are text strings designating the manner in which location information in a PIDF-LO object has been derived or discovered. Any party may register new 'method' tokens with the IANA, as needed, on a first-come-first-serve basis.
このドキュメントは、IANAがPIDF-LOオブジェクトに関連付けられた「メソッド」トークンの新しいレジストリを作成することを要求します。「メソッド」トークンは、PIDF-LOオブジェクトの位置情報が導出または発見された方法を指定するテキスト文字列です。すべての当事者は、必要に応じて、新しい「メソッド」トークンをIANAに登録して、先着順に登録できます。
This section pre-registers 7 new 'method' tokens associated with the 'method' element described above in Section 2.2.3:
このセクションは、上記のセクション2.2.3で説明した「メソッド」要素に関連付けられた7の新しい「メソッド」トークンを事前に登録します。
GPS: Global Positioning System A-GPS: GPS with assistance Manual: entered manually by an operator or user, e.g., based on subscriber billing or service location information DHCP: provided by DHCP (used for wireline access networks, see 802.11 below) Triangulation: triangulated from time-of-arrival, signal strength, or similar measurements Cell: location of the cellular radio antenna 802.11: 802.11 access point (used for DHCP-based provisioning over wireless access networks)
GPS：グローバルポジショニングシステムA-GPS：支援マニュアルを備えたGPS：たとえば、サブスクライバー請求またはサービスの位置情報に基づいてオペレーターまたはユーザーが手動で入力します。到着時、信号強度、または同様の測定セルから三角測量セル：セルラー無線アンテナの位置802.11：802.11アクセスポイント（ワイヤレスアクセスネットワークを介したDHCPベースのプロビジョニングに使用）
This document requests that IANA create a new registry of XML namespaces for 'provided-by' elements for use with PIDF-LO objects. Registrations of new XML namespaces that are used for 'provided-by' MUST be reviewed by an Expert Reviewer designated by the IESG.
このドキュメントでは、IANAがPIDF-LOオブジェクトで使用する「提供された」要素のXMLネームスペースの新しいレジストリを作成することを要求します。「提供された」に使用される新しいXMLネームスペースの登録は、IESGによって指定された専門家のレビューアがレビューする必要があります。
This document pre-registers a single XML namespace for 'provided-by', which is given in Appendix A.
このドキュメントは、付録Aに示されている「提供された」ための単一のXMLネームスペースを事前に登録します。
This section registers a new XML namespace, as per the guidelines in [4].
このセクションでは、[4]のガイドラインに従って、新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:geopriv10. Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz). XML:
URI：この名前空間のURIはurn：ietf：params：xml：ns：pidf：geopriv10です。登録者の連絡先：IETF、GEOPRIVワーキンググループ、（geopriv@ietf.org）、Jon Peterson（jon.peterson@neustar.biz）。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>GEOPRIV PIDF Extensions</title>
</head>
<body>
<h1>PIDF Extensions of Geographical Information and Privacy</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
RFC4119</a>.</p>
</body>
</html>
END
This document was produced with the assistance of many members of the GEOPRIV IETF working group. Special thanks to Carl Reed of OpenGIS for a close read of the document.
この文書は、Geopriv IETFワーキンググループの多くのメンバーの支援を受けて作成されました。文書をよく読んでくれたOpenGisのCarl Reedに感謝します。
The civic location format described in this document was proposed by Henning Schulzrinne for communicating location information in DHCP, and has been appropriated in its entirety for this document.
このドキュメントで説明されている市民の場所形式は、DHCPの位置情報を伝えたことでHenning Schulzrinneによって提案され、この文書のために完全に割り当てられています。
James M. Polk provided the text related to the 'method' element, and much of the text for the 'provided-by' element. The text of Appendix A was written by Nadine Abbott.
ジェームズ・M・ポークは、「メソッド」要素に関連するテキストと、「提供された」要素のテキストの多くを提供しました。付録Aのテキストは、Nadine Abbottによって書かれました。
A. Appendix: NENA Provided-By Schema
A.付録：Nenaが提供するスキーマ
The following registers the XML namespace urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the associated schema below, for usage within the 'provided-by' element of PIDF-LO. The dataProvider namespace was developed by the US National Emergency Number Administration (NENA) for next-generation emergency communications needs.
以下の登録XML名空間urn：ietf：params：xml：ns：pidf：geopriv10：dataproviderおよび以下の関連スキーマ。DataProviderの名前空間は、次世代の緊急通信のニーズのために米国国家緊急番号局（NENA）によって開発されました。
This appendix is non-normative for implementers of PIDF-LO implementations and MAY support the dataProvider namespace. Other registrants of 'provided-by' namespaces are invited to use the registration below as an informative example.
この付録は、PIDF-LOの実装の実装者にとっては非規範的であり、DataProvider Namespaceをサポートする場合があります。「提供された」名前空間の他の登録者は、以下の登録を有益な例として使用するよう招待されています。
URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider Registrant Contact: NENA, VoIP working group & IETF, GEOPRIV working group, (geopriv@ietf.org), Nadine Abbott (nabbott@telcordia.com). XML:
URI：この名前空間のURIはurn：ietf：params：xml：ns：pidf：geopriv10：geopriv10：dataprovider登録者の連絡先：nena、voipワーキンググループ＆ietf、geopriv@ietf.org）、ナディーンアボット（ナブボット@telcordia.com）。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>NENA dataProvider Schema for PIDF-LO</title>
</head>
<body>
<h1>NENA dataProvider Schema for 'provided-by' in PIDF-LO</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
RFC4119</a>.</p>
</body>
</html>
END
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by
Patricia Bluhm (HBF Group) -->
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="nena" type="tns:DataProviderIDType"/>
<xs:complexType name="DataProviderIDType">
<xs:annotation>
<xs:documentation>NENA registered Company ID
for Service Provider supplying location information</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="DataProviderID"
type="tns:NENACompanyIDType" minOccurs="0"/>
<xs:element name="TelURI"
type="tns:TelURI_24x7Type" minOccurs="0"/>
<xs:element name="URL" type="xs:anyURI"
minOccurs="0"/>
</xs:all>
</xs:complexType>
<xs:simpleType name="NENACompanyIDType">
<xs:annotation>
<xs:documentation>NENA registered Company
ID.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="5"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="TelURI_24x7Type">
<xs:annotation>
<xs:documentation>24x7 Tel URI for the
caller's [location data] service provider. To be used for contacting
service provider to resolve problems with location data. Possible
values TN number, enumerated values when not
available.</xs:documentation>
</xs:annotation>
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:maxLength value="10"/>
<xs:enumeration value="NOT FOUND"/>
<xs:enumeration value="UNAVAILABLE"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:schema>
Normative References
引用文献
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[2] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, October 2003.
[3] ピーターソン、J。、「存在のための共通プロファイル（CPP）」、RFC 3859、2003年10月。
[4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 2004.
[4] Mealling、M。、「IETF XMLレジストリ」、RFC 3688、BCP 81、2004年1月。
[5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[5] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[6] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[7] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[7] Levinson、E。、「コンテンツIDおよびメッセージIDユニフォームリソースロケーター」、RFC 2392、1998年8月。
[8] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[8] Schaad、J。、「暗号化メッセージ構文（CMS）での高度な暗号化標準（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[9] Ramsdell、B。、「セキュア/多目的インターネットメール拡張機能（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
Informative References
参考引用
[10] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[10] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。
[11] Morris, J., Mulligan, D., and J. Cuellar, "Core Privacy Protections for Geopriv Location Object", Work in Progress, June 2003.
[11] Morris、J.、Mulligan、D。、およびJ. Cuellar、「Geopriv Location Objectのコアプライバシー保護」、2003年6月、進行中の作業。
[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[12] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[13] Peterson, J., "A Presence Architecture for the Distribution of Geopriv Location Objects", Work in Progress, February 20003.
[13] Peterson、J。、「Geoprivロケーションオブジェクトの分布のための存在アーキテクチャ」、20003年2月、進行中の作業。
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[14] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年5月。
[15] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OGC 02-023r4, January 2003, <http://www.opengeospatial.org/specs/?page=specs>.
[15] OpenGis、「Open Geography Markup Language（GML）実装仕様」、OGC 02-023R4、2003年1月、<http://www.opengeospatial.org/specs/?page=specs>。
[16] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[16] Danley、M.、Mulligan、D.、Morris、J。、およびJ. Peterson、「Geoprivプロトコルの脅威分析」、RFC 3694、2004年2月。
Author's Address
著者の連絡先
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。