[要約] RFC 4119は、プレゼンス情報（在席確認）の中で個人の位置情報を安全に伝達するための「GEOPRIV」ロケーションオブジェクトのXMLフォーマットを定義しています。緯度経度などの位置データに、保持期間や再配布の可否といったプライバシーポリシーを直接付随させ、ユーザーが自身の情報を制御できる仕組みを提供します。
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.
この文書は、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを定め、改善に向けた議論や提案を求めています。このプロトコルの標準化状況については、「Internet Official Protocol Standards」（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.
この文書は、インターネット上で地理的位置情報を伝送するためのオブジェクト形式を説明します。この位置オブジェクトは、プライバシーに関わるプレゼンス情報の伝達を目的とし、同様の性質を持つPresence Information Data Format（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.
地理的位置情報は、人、出来事、またはデバイスの過去・現在・将来の物理的位置を表します。現在のインターネット上には、地図・ナビゲーションアプリや携帯電話の「友人検索」など、位置情報の共有を利用する多くのアプリケーションがあります。一方、そのようなアプリケーションが、ユーザーの希望に反して人物の所在を開示することもあります。盗聴者による位置情報の取得を許すプロトコルのセキュリティ不足、ユーザーの希望を表現または反映できないことなど、既存システムに共通する問題がプライバシー侵害につながります。本人が望まない物理的位置の開示は、インターネット利用者が直面する深刻なプライバシー問題の一つです。
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ベースのPresence Information Data Format（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].
この文書で使われるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、[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文書の「presence」要素には「entity」属性があり、文書がプレゼンスを記述する対象のURIを示します。したがって、PIDF文書に位置情報が含まれる場合、「presence」要素の「entity」属性のURIが位置情報の対象（「presentity」）を示します。「entity」属性のURIには通常、[3]で定義される「pres」URIスキームを使います。このようなURIは、相互に関連付けられない仮名として機能できます（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には任意の「contact」要素があり、プレゼンティティに何らかの通信手段で到達するためのURIを示します。通常、「contact」要素の値に使うURIスキームから、到達方法が分かります。たとえばSIP URIスキームならSIPで通信できます。位置情報は通信手段と関連付けずに提供することもできます。そのため、「contact」要素を含めるかどうかは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には任意の「timestamp」要素があり、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には必須の「status」要素があります。「status」には任意の子要素「basic」が含まれ、プレゼンティティの通信状態を大まかにOPENまたはCLOSEDで示します。この文書の目的では、「basic」状態を含める必要はありません。ただし、地理的位置情報に加えて通信状態をPIDF文書に含める場合、この拡張を使うPIDF文書に「basic」状態を含めてもかまいません。
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には「tuple」という包含要素もあります。この要素は、プレゼンス情報の一部分を一意に識別する「id」要素を保持し、複数のプレゼンス通知を受け取る間にその情報の変化を追跡できるようにします。「timestamp」「status」「contact」は「tuple」の下に置かれます。
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スキーマは、PIDFの「status」要素を「geopriv」という複合要素で拡張します。「geopriv」には、位置情報用と利用規則用の2つの主要な子要素が含まれます。両方とも必須であり、後続の節で説明します。この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つは地理的位置の決定方法を示し、もう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'要素は、'location-info'要素を1つ含まなければなりません (MUST)。'location-info'要素は、1つ以上の位置情報のまとまりで構成されます（REQ 2.5）。位置情報の形式（REQ 2.6）は、対象の名前空間を記述するインポート済みXMLスキーマで識別します。'geopriv'要素を含むすべてのPIDF文書は、地理的位置形式に使用するXMLスキーマを示すimportディレクティブを1つ以上含まなければなりません (MUST)。
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を満たすことから、この文書ではGeography Markup Language（GML）3.0 [15]を必須形式とします。つまり、'geopriv'要素をサポートするすべてのPIDF実装は、GML 3.0を実装しなければなりません (MUST)。
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 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:
GMLは、さまざまな地理オブジェクトの型、トポロジー、メタデータ、座標参照系、測定単位をモデル化できる、非常に包括的で柔軟なシステムです。位置情報を扱うGMLの最も簡単なパッケージは'feature.xsd'スキーマです。'feature.xsd'は複雑な地理概念を表現できますが、よく使われる基本的な座標点を記述するために必要なマークアップはわずかです。緯度・経度に基づく位置情報を含むさまざまな形式は、Featureでサポートされています（例は[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.
Featureスキーマをインポートすると、必要な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スキーマのサポートだけが必須です (REQUIRED)。
Implementations MAY support the civic location format (civicLoc) defined in Section 2.2.5. civicLoc provides the following elements:
実装は、セクション2.2.5で定義する住所形式（civicLoc）をサポートしてもよいです (MAY)。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'）は、'location-info'要素に含めてもよいです (MAY)。両方を同じ'location-info'要素に含めてもかまいません (MAY)。要約すると、この仕様に準拠する実装はGML 3.0のfeature.xsdスキーマをサポートしなければならず (MUST)、civicLoc形式をサポートしてもかまいません (MAY)。
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 Maker has requested that all subelements be given their default values.
この文書の作成時点では、GEOPRIVオブジェクトのポリシー要件はまだ確定していませんでした。しかし、'usage-rules'要素はREQ 2.8とGEOPRIVポリシー要件文書[11]の要件を満たすために設けられています。各'geopriv'要素は、ルール作成者がすべての子要素にデフォルト値を求めている場合でも、'usage-rules'要素を1つ含まなければなりません (MUST)。
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つあります。再送信を制限するフィールド、保持期間を制限するフィールド、外部ルールセットへの参照を含むフィールドです。最初の3つの要素がこれらのフィールドに対応します。4つ目の要素は、人が読めるポリシー指示を記述するための汎用領域です。これらのフィールドは、位置オブジェクトの'usage-rules'要素に含めてもよいです (MAY)。いずれも必須ではありません。
'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.
'retransmission-allowed'：この要素の値が'no'の場合、位置オブジェクトの受信者は、含まれる位置情報もオブジェクト全体も他者と共有することを許されません。値が'yes'の場合、既存の帯域外合意や反対の義務がなければ、その位置情報を配布できます。デフォルト値は'no'と想定しなければなりません (MUST)。ルール作成者が希望を指定しない場合、実装はこのフィールドを含め、その値を'no'にしなければなりません (MUST)。
'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.
'retention-expires'：このフィールドは、受信者が位置情報およびそれを格納する位置オブジェクトを保有できなくなる絶対時刻を指定します。両方とも、このフィールドが示す時刻までしか保持できません。デフォルトでは、PIDF文書に'timestamp'要素がある場合、その時刻から24時間後を値と想定しなければなりません (MUST)。'timestamp'要素もない場合は、位置オブジェクトを位置受信者が受信した時刻から24時間後を値と想定しなければなりません (MUST)。位置受信者が受け取った時点で'retention-expires'要素の値を過ぎている場合、受信者は位置オブジェクトを直ちに破棄しなければなりません (MUST)。
'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スキームを使うべきです (SHOULD)。HTTPSを使う場合、ルールを保持するサーバーは、ルールへのアクセス要求をすべて認証しなければなりません (MUST)。利用規則自体が、対象者やルール作成者の個人情報を明らかにすることがあります。URIには代わりにCID URIスキーム[7]を使ってもよいです (MAY)。その場合、利用プロトコルによって位置オブジェクトとともに運ばれるMIMEボディを示さなければなりません (MUST)。MIMEボディで運ばれるルールセットは、ルール作成者が暗号化し署名すべきです (SHOULD)。署名のないルールセットを位置サーバーや位置受信者が受け入れるべきではありません (SHOULD NOT)。認可失敗となるネットワーク照会を避けるため、位置オブジェクトの作成者は、CIDが参照する暗号化済み外部MIMEボディにHTTPSベースのルールセット参照を格納してもよいです (MAY)。こうすれば、外部MIMEボディを復号できない受信者には、そのボディを復号できない限り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'要素は、位置情報を導出または特定した方法を示します。地理的位置システムにおけるこの要素の例を次に示します：
<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.
'method'要素で使える値はIANAレジストリに列挙されます。実装は、このmethodにIANAが管理する値だけを使用しなければなりません (MUST)。この文書では、IANAレジストリに7つの値をあらかじめ登録します。詳細はセクション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.
たとえば、複数の情報源が同じユーザーの位置情報を報告し、その位置の特定方法によって信頼性に差がある場合（動的なリアルタイム位置測定と、対象デバイスに設定済みの静的情報など）、'method'要素が役立ちます。ただし、生成者が意図的に精度を落とした位置情報を提供している場合、'method'を含めることで機密情報が明らかになる可能性があります。たとえば、位置オブジェクト（LO）の'method'が'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'要素は、署名証明書から推測できるドメイン情報に加えて、位置情報を提供した主体または組織を示します。架空のゲームシステムにおけるこの要素の例を次に示します：
<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.
'provided-by'要素の値は、IANAに登録されたXML名前空間でなければなりません (MUST)。詳細はセクション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.
'provided-by'要素は、ほとんどの主体が使うことを想定していません。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.
通常、位置情報を提供した主体は、位置オブジェクトの署名に使った証明書のsubjectAltNameで伝えられるため、この要素は不要です。'Provided-by'は、緊急サービスを多様な国の状況で提供する場合など、複雑な管理ドメイン内の特定のシステムまたは当事者を位置オブジェクト作成者が指定したいときに有用です。たとえば、形式不正または誤解を招く位置オブジェクトを受信した人が、障害を起こしたシステムを特定する助けになります。
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.
この情報は、意図せず受信者に追加情報を与え、地理情報や住所情報の実効的な精度を高めたり、完全に保護するはずだった位置情報を明らかにしたりすることがあるため、注意が必要です。コロンビア大学が'provided-by'要素を登録して使用することになった事情を考えてください。例の位置オブジェクトが州レベルの情報しか含まなくても、位置情報の提供元がコロンビア大学だと分かれば、対象者が実際にはマンハッタンの4ブロックほどの区域にいると強く推測できます。したがって、この要素は組織の業務が大きく依存する場合に限って使うべきです。それ以外は証明書のsubjectAltNameで十分であり、'provided-by'を使うべきではありません (SHOULD NOT)。
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]には、REQ 2.10に従ってバージョン番号1.0が含まれることに注意してください。
<?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'スキーマは、'usage-rules'要素用に次のポリシースキーマをインポートします。このスキーマは再利用できるよう、基本の地理位置オブジェクトから分離されています。セクション2.2.2で説明した要素の意味は、地理位置オブジェクトのポリシーを定義する目的でこれらの要素を使う場合に限り適用されます。それ以外の用途で'usage-rules'を使う場合は、そのすべての子要素の意味を別途定義する必要があります。
<?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.
次のスキーマは住所情報を簡略に表現するものであり、この仕様に準拠する主体は実装してもよいです (MAY)。
<?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文書であるため、XMLを運べるプロトコルであればPIDFを運べます。PIDF用のMIMEタイプ'application/pidf+xml'も登録されています。そのため、SMTP、HTTP、SIPなどMIMEを使うプロトコルでは、Content-Typeが'application/pidf+xml'であることを含むMIMEヘッダー一式で包み、PIDFを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をサポートしなければなりません (MUST)。特に、暗号化とデジタル署名にそれぞれ使うCMS [6]のEnvelopedDataとSignedDataコンテンツタイプをサポートしなければなりません (MUST)。この方式は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暗号化アルゴリズムを実装しなければなりません (MUST)。もちろん、実装はS/MIME仕様で説明されている基本の暗号化アルゴリズムとデジタル署名アルゴリズムもサポートしなければなりません (MUST)。
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証明書をサポートすべきです (SHOULD)。また、パスワードベースのCMS暗号化をサポートしなければなりません (MUST)（[6]を参照）。対称鍵方式では、高エントロピーのコンテンツ暗号化鍵（CEK）を導出すべきです (SHOULD)。X.509証明書でPIDF位置オブジェクトに署名する場合、証明書のsubjectAltNameには「pres」URIスキームを使うべきです (SHOULD)。
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を使う展開モデルの一例を示します。位置サーバーは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 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).
S/MIMEは、メッセージ本文を変更しない複数のサーバー（メール転送エージェントなど）を介して通信するメール当事者間のエンドツーエンドセキュリティを想定して設計されています。しかし、ルール作成者に代わってポリシーを適用する場合など、位置サーバーが位置オブジェクトを変更することがあります。たとえばルール作成者は、特定の受信者に送信する前に位置情報の精度を落とすよう指定できます。位置オブジェクトが暗号化、署名、またはその両方で保護されていて位置サーバーが変更できない場合、この処理を実行できません。そのため、位置生成者が位置サーバーによるメッセージ変更を許可する場合、サーバーが復号できる鍵でメッセージを暗号化してもよいです (MAY)。もちろん、デジタル署名には引き続き位置生成者の証明書の鍵素材を使えます。位置オブジェクトを変更した後、位置サーバーは自身の資格情報でオブジェクトに再署名でき、サーバーが知っていれば位置受信者に発行された鍵で再暗号化できます。
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]に詳述されています。脅威モデルの分析で特定された要件は[10]に反映され、特にセクション7.4で扱われています。この文書は、これら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.
この文書は、PIDF-LOオブジェクトに関連付ける'method'トークンの新しいレジストリをIANAに作成するよう求めます。'method'トークンは、PIDF-LOオブジェクトの位置情報を導出または特定した方法を示すテキスト文字列です。必要に応じて、どの当事者も先着順で新しい'method'トークンをIANAに登録できます。
This section pre-registers 7 new 'method' tokens associated with the 'method' element described above in Section 2.2.3:
この節では、セクション2.2.3で説明した'method'要素に関連する7つの'method'トークンをあらかじめ登録します：
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。Manual：オペレーターまたはユーザーが手動入力（加入者課金情報やサービス提供位置情報に基づく入力など）。DHCP：DHCPによる提供（有線アクセスネットワークで使用。無線アクセスネットワークでのDHCPベースの設定には、下記の802.11を参照）。Triangulation：到着時刻、信号強度などの測定値による三角測量。Cell：セルラー無線アンテナの位置。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.
この文書は、PIDF-LOオブジェクトの'provided-by'要素に使うXML名前空間の新しいレジストリをIANAに作成するよう求めます。'provided-by'用の新しいXML名前空間の登録は、IESGが指定する専門家レビュアーの審査を受けなければなりません (MUST)。
This document pre-registers a single XML namespace for 'provided-by', which is given in Appendix A.
この文書では、'provided-by'用のXML名前空間を1つあらかじめ登録します。値は付録Aに示します。
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.
James M. Polkは'method'要素に関する文章と、'provided-by'要素に関する文章の大部分を提供しました。付録AはNadine Abbottが執筆しました。
A. Appendix: NENA Provided-By Schema
付録A：NENAのProvided-Byスキーマ
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.
以下では、PIDF-LOの'provided-by'要素内で使うXML名前空間urn:ietf:params:xml:ns:pidf:geopriv10:dataProviderと、以下に示す関連スキーマを登録します。dataProvider名前空間は、次世代緊急通信の要件に対応するため、米国National Emergency Number Association（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名前空間をサポートしてもよいです (MAY)。他の'provided-by'名前空間の登録者は、以下の登録を参考例として利用できます。
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:dataProviderです。登録者の連絡先：NENA, VoIP working group & IETF, GEOPRIV working group, (geopriv@ietf.org), Nadine Abbott (nabbott@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>
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[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., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, October 2003.
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, October 2003.
[4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 2004.
[4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January 2004.
[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 Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[7] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[7] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
[8] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[8] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[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., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[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., and J. Cuellar, "Core Privacy Protections for Geopriv Location Object", Work in Progress, June 2003.
[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[13] Peterson, J., "A Presence Architecture for the Distribution of Geopriv Location Objects", Work in Progress, February 20003.
[13] Peterson, J., "A Presence Architecture for the Distribution of Geopriv Location Objects", Work in Progress, February 20003.
[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., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[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) Implementation Specification", OGC 02-023r4, January 2003, <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., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
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に定められた権利、ライセンス、制限に従います。同BCPに記載された場合を除き、著者はすべての権利を保持します。
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.
この文書およびここに含まれる情報は「現状有姿」で提供されます。貢献者、その貢献者が代表する組織または後援を受ける組織（該当する場合）、Internet Society、およびInternet Engineering Task Forceは、明示または黙示を問わず、すべての保証を否認します。これには、ここに含まれる情報の使用がいかなる権利も侵害しないこと、商品性の黙示保証、特定目的への適合性の黙示保証が含まれますが、これらに限定されません。
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に知らせるよう求めます。情報はietf-ipr@ietf.org宛てに送付してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在Internet Societyが提供しています。