Network Working Group                                        J. Peterson
Request for Comments: 4119                                       NeuStar
Category: Standards Track                                  December 2005
        
            A Presence-based GEOPRIV Location Object Format
        

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).

著作権(C)インターネット協会(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
        
1. Introduction
1. はじめに

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ベースのプレゼンス情報データフォーマットを拡張(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の。しかしながら、この位置オブジェクトフォーマットの使用はPIDFを運ぶことができるXMLまたはMIMEタイプを運ぶことができる任意のプロトコルをprotocols--存在は、使用に限定されるものではありません。

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])によって指定されるように、必要なプライバシー設定を表現するユーザーのために必要な最小限のマークアップを提供します。しかし、この文書はPIDFに埋め込むことができ、ロケーションサーバのニーズを収容し、どのように完全なXMLベースのルールセットを示すものではありません。 (HTTPなど)他のプロトコルは、ルールホルダーとロケーションサーバとの間でルールを移動させるために使用されることが想定され、その完全なルールセットは、別の文書で定義されます。

1.1. Conventions Used in This Document
1.1. このドキュメントの表記規則

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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。

2. Location Object Format
2.場所のオブジェクトフォーマット
2.1. Baseline PIDF Usage
2.1. ベースラインPIDFの使い方

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スキームを使用します。そのような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は任意にプレゼンティティが通信するいくつかの手段によって到達することができる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は必須である「状態」要素が含まれています。 「状況は」(:OPENまたはCLOSEDのいずれかの非常に広い意味での)プレゼンの通信処分を記述するオプションの子要素、「基本」を、含まれています。 「基本的な」ステータスが含まれるため、このドキュメントの目的のために、それは必要ありません。しかし、通信配置は上記とジオロケーションを超えた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」要素を保持している「タプル」傘要素を含んでいます。 「タイムスタンプ」、「ステータス」、および「接触」は「タプル」の下に構成されています。

2.2. Extensions to PIDF for Location and Usage Rules
2.2. 場所や使い方のルールのためのPIDFの拡張

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の「状態」要素を拡張します。位置情報の一つであり、使用規則のための1:geopriv内にカプセル化されている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」要素の下に表示することができます。二つの他の任意のサブエレメントは、本文書に含まれています:地理的位置が決定された方法を示す1、および情報を提供するエンティティの明示的な指定を可能にするものです。

2.2.1. 'location-info' Element
2.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「位置情報」要素を含まなければなりません。 「位置情報」要素(REQ 2.5当たりの)位置情報の1つのまたは複数のチャンクから成ります。位置情報(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

URN:OpenGISの:仕様:GML:スキーマのxsd:機能: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」)のいずれかで、「位置情報」要素に表示されることがあります。どちらも同じ「位置情報」要素に使用されるかもしれません。要約すると、GML 3.0のfeature.xsdスキーマはこの仕様に準拠した実装によってサポートされなければならない、とcivicLoc形式はこの仕様に準拠した実装によって支持されてもよいです。

2.2.2. 'usage-rules' Element
2.2.2. 「利用ルール」要素

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.

メーカーは、すべてのサブ要素がそのデフォルト値を与えることを要求しています。

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.

への参照を含む1つの再送を制限し、フィールド、保有を制限1、および1:ポリシーの要件の文書(3.1節)に続いて、(発電機から受信者への)ライフサイクル全体でのLocationオブジェクトで表現する必要がある3つのフィールドがあります外部ルールセット。これらの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.

「保持は、有効期限が切れ」:このフィールドは、受信者は、もはや位置情報とそのカプセル場所オブジェクトを所有することを許可された時点で絶対的な日付を指定します。両方は、このフィールドで指定された時間まで保持することができます。存在する場合、デフォルトでは、値は、PIDF文書の「タイムスタンプ」要素から一昼夜であると仮定しなければなりません。 「タイムスタンプ」要素も存在しない場合、その値は、ロケーションオブジェクトが場所受信者によって受信された時点から一昼夜であると仮定しなければなりません。場所受信者は、場所オブジェクトを受信したときに「リテンション期限が切れる」要素の値がすでに過ぎている場合、受信者はすぐに場所オブジェクトを捨てなければなりません。

'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.

「ルールセット・リファレンス」:このフィールドには、このオブジェクトに関連した政策の充実ルールセットが、見つけることができる場所を示すというURIが含まれています。このURIは、HTTPS URIスキームを使用する必要があります。それがない場合は、これらのルールを保持しているサーバーは、これらのルールにアクセスしようとする試みを認証しなければなりません。使い方自体はターゲットやルールの製造元についての個人情報を漏らすことがルール。 URI MAYは、代わりに、それが使用プロトコルによってロケーションオブジェクトに運ばMIME本体を示す必要がある場合にCID URIスキーム[7]を使用します。 MIMEボディとして実施ルールセットは、ルールメーカーによって暗号化および署名されるべきです。符号なしのルールセットは、ロケーションサーバや場所の受信者によって光栄れるべきではありません。認証の失敗につながるネットワークのルックアップを避けるために、ロケーションオブジェクトの作成者はCIDによって参照暗号化された外部MIMEボディにHTTPSベースのルールセット・リファレンスを置いてもよいことに注意してください。彼らはMIMEボディを解読することができない限り、このように、外部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.

「ノートウェル」:このフィールドは、さらに、一般的なプライバシーのディレクティブを含むテキストのブロックが含まれています。これらのディレクティブは、任意のオートマトンによって処理されるべきではなく、人間だけが読めるように意図されています。

2.2.3. 'method' Element
2.2.3. 「メソッド」要素

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>

<方法> GPS </方法>

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」で送信するが、位置情報は、発電機が配置されている唯一の都市を示している場合、例えば、送信者がいくつかの位置情報が保留されていることを疑うに良い正当性を有しています。

2.2.4. 'provided-by' Element
2.2.4. 「提供-によって」要素

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.

一般的なケースでは、位置情報を供給するエンティティは、ロケーション・オブジェクトが署名している証明書のsubjectAltNameによって通信されます。したがって、この要素は不要です。ロケーションオブジェクトの作成者が多様な国家のコンテキストで緊急サービスを提供するために想定される状況を含め、複雑な管理ドメイン内の特定のシステムやパーティーを指定したい場合「提供-によって」特定のケースでは意味があります。これは、故障特定のシステムを識別する際に、例えば、不正なまたは誤解を招く位置オブジェクトの受信者を支援するかもしれません。

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つのブロック領域に位置しているという強力な指標を提供します。したがって、この要素は、組織の機能が強く、それに依存する場合にのみ使用する必要があります。このような用途が、すべてでは、証明書ののsubjectAltNameは十分であろう、と「提供 - 」によって使用されるべきではありません。

2.2.5. Schema Definitions
2.2.5. スキーマ定義

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">

<?xml version = "1.0" エンコード= "UTF-8"?> <XS:スキーマのtargetNamespace = "壷:IETF:のparams:XML:NS:PIDF:geopriv10" のxmlns:TNS = "壷: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要素=」資格の」attributeFormDefault = "非修飾">

<xs:import namespace= "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" />

<XS:インポートの名前空間= "壷:IETF:のparams:XML:NS:PIDF:geopriv10:basicPolicy" />

<!-- This import brings in the XML language attribute xml:lang-->

<! - このインポートは、XML言語の属性xmlにもたらします:langの - >

<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>

<XS:インポート名前空間= "http://www.w3.org/XML/1998/namespace" のschemaLocation = "http://www.w3.org/2001/xml.xsd" />

<xs:element name="geopriv" type="tns:geopriv"/>

<XS:要素名= "geopriv" タイプ= "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の名前= "geopriv"> <XS:配列> <XS:要素名= "位置情報" タイプ= "TNS:locInfoType" のminOccurs = "1" のmaxOccurs = "1" /> <XS:要素名= "利用ルール" タイプ= "GBP:locPolicyType" のminOccurs = "1" のmaxOccurs = "1" /> <XS:要素名= "方法" タイプ= "TNS:locMethod" のminOccurs = "0" のmaxOccurs = "1 locProvidedBy "のminOccurs = "0" のmaxOccurs = "1"/> <XS:任意の名前空間= "##その他" のprocessContents = "緩い" minOccurs属性設けバイ」TYPE =" TNS "/> <XS要素名=" = "0" のmaxOccurs = "無制限" /> </ XS:配列> </ XS:complexTypeの>

<xs:complexType name="locInfoType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>

<XS:complexTypeの名= "locInfoType"> <XS:シーケンス> <XS:任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS:シーケンス> < / 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の名前= "locMethod"> <XS:simpleContentを> <XS:増設ベース= "XS:文字列"> <XS:属性REF = "XML:LANG" /> </ XS:拡張> </ 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:complexTypeの名前= "locProvidedBy"> <XS:シーケンス> <XS:任意の名前空間= "##他" のprocessContents = "スキップ" のminOccurs = "1" のmaxOccurs = "無制限" /> </ XS:シーケンス> < / XS:complexTypeの>

</xs:schema>

</ XS:スキーマ>

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,

「利用ルール」要素は、以下のポリシースキーマのための「geopriv10」スキーマの輸入、。このスキーマは、その再利用を可能にするために、基本的なジオロケーションオブジェクトから切断されました。 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.

唯一のジオロケーションオブジェクトのためのポリシーを定義するには、これらの要素の使用に適用されます。 「利用ルール」のいずれかの他の使用は、すべての「利用ルール」サブ要素のために独自の意味を特徴づける必要があります。

<?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">

<?xml version = "1.0" エンコード= "UTF-8"?> <XS:スキーマのtargetNamespace = "壷:IETF:のparams:XML:NS:PIDF:geopriv10:basicPolicy" のxmlns:TNS = "壷:IETF:のparams :XML:NS:PIDF:geopriv10:basicPolicy」のxmlns:XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>

<!-- 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"/>

<! - このインポートは、XML言語の属性xmlにもたらします:LANG - > <XS:インポートの名前空間= "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の名前= "locPolicyType"> <XS:配列> <XS:要素名= "再送許可" タイプ= "XS:ブール" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "保持-満了" TYPE = "XS:dateTimeの" minOccurs属性= "0" のmaxOccurs = "1" /> <XS:要素名= "外部ルールセット" TYPE = "XS:anyURIの" minOccurs属性= "0" のmaxOccurs = "1" /> <XS:要素名= "notewell" タイプ= "TNS:notewell" のminOccurs = "0" のmaxOccurs = "1" /> <XS:任意の名前空間= "##その他" のprocessContents = "LAX "のminOccurs =" 0" のmaxOccurs = "無制限" /> </ XS:配列> </ 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:complexTypeの名前= "notewell"> <XS:simpleContentを> <XS:増設ベース= "XS:文字列"> <XS:属性REF = "XML:LANG" /> </ XS:拡張> </ XS: simpleContentを> </ XS:complexTypeの>

</xs:schema>

</ XS:スキーマ>

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">

<?xml version = "1.0" エンコード= "UTF-8"?> <XS:スキーマのtargetNamespace = "壷:IETF:のparams:XML:NS:PIDF:geopriv10:civicLoc" のxmlns:TNS = "壷:IETF:のparams :XML:NS:PIDF:geopriv10:civicLoc」のxmlns:XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>

<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:complexTypeの名前= "civicAddress"> <XS:シーケンス> <XS:要素名= "国" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名=」 A1" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "A2" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> < XS:要素名= "A3" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "A4" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "A5" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "A6" タイプ= "XS:文字列" minOccurs属性= "0" のmaxOccurs = "1" /> <XS:要素名= "PRD" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "POD" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "STS" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "HNO" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "HNS" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" / > <XS:要素名= "LMK" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "LOC" タイプ= "XS:文字列" M inOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "FLR" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "NAM" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "PC" タイプ= "XS:文字列" のminOccurs = "0" のmaxOccurs = "1" /> <XS:任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS:シーケンス> </ XS:complexTypeの>

</xs:schema>

</ XS:スキーマ>

2.3. Example Location Objects
2.3. 例Locationオブジェクト

Note that these examples show PIDF documents without any MIME headers or security applied to them (see Section 4 below).

これらの例はそれらに適用されるすべてのMIMEヘッダやセキュリティ(以下のセクション4を参照)をせずにPIDFドキュメントを示すことに注意してください。

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マークアップの使用の一例です。 GPSは、サンフランシスコ、CAの「GML」要素にしている与えられた座標

<?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>

<?xml version = "1.0" エンコード= "UTF-8"?> <プレゼンスのxmlns = "URN:IETF:paramsは:XML:NS:PIDF" のxmlns:GP = "URN:IETF:paramsは:XML:NS:PIDF :geopriv10" のxmlns:GML = "URN:OpenGISの:仕様:GML:スキーマのxsd:機能:V3.0" エンティティ= "PRES:geotarget@example.com"> <タプルID = "sg89ae"> <状態> < GP:geopriv> <GP:ロケーション情報> <GML:場所> <GML:ポイントGML:ID = "POINT1" srsName = "EPSG:4326"> <GML:座標> 37:46:30N 122:25:10W </ GML:座標> </ GML:ポイント> </ GML:場所> </ GP:ロケーション情報> <GP:利用ルール> <GP:再送許容>ない</ GP:再送せ> < GP:保持-期限> 2003-06-23T04:57:29Z </ GP:保持-期限> </ GP:利用ルール> </ GP:geopriv> </状態> <タイムスタンプ> 2003-06-22T20: 57:29Z </タイムスタンプ> </タプル> </プレゼンス>

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>

<?xml version = "1.0" エンコード= "UTF-8"?> <プレゼンスの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" エンティティ= "PRES:geotarget@example.com"> <タプルID = "sg89ae"> <状態> <GP: geopriv> <GP:ロケーション情報>

<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>

<CL:civicAddress> <CL:国>アメリカ</ CL:国> <CL:A1>ニューヨーク</ CL:A1> <CL:A3>ニューヨーク</ CL:A3> <CL:A6>ブロードウェイ< / CL:A6> <CL:HNO> 123 </ CL:HNO> <CL:LOC>スイート75 </ CL:LOC> <CL:PC> 10027から0401 </ CL:PC> </ CL:civicAddress> </ GP:場所-インフォメーション> <GP:利用ルール> <GP:再送許可>はい</ GP:再送許可> <GP:保持-期限> 2003-06-23T04:57:29Z </ GP :保持-期限> </ GP:利用ルール> </ GP:geopriv> </状態> <タイムスタンプ> 2003-06-22T20:57:29Z </タイムスタンプ> </タプル> </プレゼンス>

3. Carrying PIDF in a Using Protocol
3.使用するプロトコルでPIDFキャリング

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のために登録されている:「アプリケーション/ PIDF + XML」を。 PIDFは、したがって、「アプリケーション/ PIDF + XML」のコンテンツタイプを含むMIMEヘッダのカプセル化セットを用いて(例えば、SMTP、HTTP、またはSIPのような)MIMEを使用するプロトコルにMIME本体として実施することができます。

Further specification of the behavior of using protocols (including subscribing to or requesting presence information) is outside the scope of this document.

(プレゼンス情報にサブスクライブまたは要求を含む)プロトコルを使用しての動作の更なる仕様は、この文書の範囲外です。

4. Securing PIDF
4.確保PIDF

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コンテンツタイプをサポートしなければなりません。なお、この機構はREQS 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証明書をサポートすべきである、と([6]参照)、パスワードベースのCMSの暗号化をサポートしなければなりません。任意の対称鍵システムは、高エントロピー符号化コンテンツ鍵(たCEK)を導出すべきです。 X.509証明書はPIDF場所オブジェクトに署名するために使用されている場合は、証明書ののsubjectAltNameは、「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のための一つの想定される展開モデルは以下の通りです。ロケーションサーバは、ロケーション・ジェネレータと場所受信者に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つのインスタンスは、しかし、があります。例えば、ルールメーカーは、それが特定の受信者に送信される前に、位置情報は、(以下特定製)を粗大化されるべきであることを指定してもよいです。それは暗号化されたため、ロケーションサーバは、ロケーションオブジェクトを変更することができなかった場合は、署名、またはその両方が、この機能を達成することができないであろう。場所Generatorはロケーションサーバは、このようなメッセージを変更できるようにしたいときにその結果、彼らはまだから材料をキーイングで作成することができ、当然のロケーションサーバによって解読することができるキー(デジタル署名、とのようなメッセージを暗号化してもよいです場所ジェネレーターの証明書)。 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).

(それらはサーバーに知られている場合は、所在地の受信者に発行された任意のキーで暗号化)サーバーは、独自の資格情報を持つオブジェクトを再署名することができます。

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項で説明されていますということ。

5. Security Considerations
5.セキュリティについての考慮事項

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]に組み込まれました。この文書は、これまで(使用プロトコルとは対照的に)それらが位置オブジェクト自体に適用されるように、これら二つの事業に由来するセキュリティ要件に準拠することを目的とします。

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.

実装のための規範的要件を含め、この文書で定義された場所オブジェクトのセキュリティは、このセキュリティは、S / MIMEを経由してその生涯の場所のオブジェクトに適用され、エンドツーエンドの完全性と機密性の特性に焦点を当てて、セクション4で説明されています。

Security requirements associated with using protocols (including authentication of subscribers to geographical information, etc.) are outside the scope of this document.

(地理情報などの加入者の認証を含む)のプロトコルを使用して関連付けられたセキュリティ要件は、この文書の範囲外です。

6. IANA Considerations
6. IANAの考慮事項
6.1. 'method' Tokens
6.1. 「メソッド」トークン

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は:加入者の課金またはサービスの位置情報をDHCPに基づいて、例えば、オペレータまたはユーザにより手動で入力された:DHCPによって提供される三角形(以下802.11を参照して、有線アクセス・ネットワークのために使用されます)。到着時間、信号強度、又は同様の測定セルから三角:セルラー無線アンテナ802.11の場所:(無線アクセス・ネットワーク上でDHCPベースのプロビジョニングに使用される)、802.11アクセスポイント

6.2. 'provided-by' Elements
6.2. 「提供-で」要素

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名前空間を、事前に登録します

6.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10

6.3. 骨壷のためのURNサブ名前空間の登録:IETF:のparams:XML:NS:PIDF:geopriv10

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:IETF::のparams:XML:NS:PIDF:geopriv10この名前空間のURIはURNです。登録者連絡先:IETF、GEOPRIVワーキンググループ、(geopriv@ietf.org)、ジョン・ピーターソン(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">

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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" /> <タイトル> GEOPRIV PIDF拡張機能</ TITLE> </ HEAD> <BODY> <H1>地理情報とプライバシーのPIDF拡張</ H1> <H2> URN:IETF:のparams:XML:NS: PIDF:geopriv10 </ H2> <P>を参照してください。<a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">

RFC4119</a>.</p> </body> </html> END

RFC4119 </a>でます。</ p> </ body> </ html>このEND

7. Acknowledgements
7.謝辞

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のカール・リードに感謝します。

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で位置情報を通信するためヘンイング・シュルツリンによって提案された、この文書のためにその全体が充当されています。

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のテキストは、ナディーヌ・アボットによって書かれました。

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のと内使用については、以下の関連するスキーマ、 '提供バイ' PIDF-LOの要素。 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の名前空間をサポートするかもしれません。 「提供-によって」名前空間の他の登録者は、有益例として、以下の登録を使用するために招待されています。

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のワーキンググループ&IETF、GEOPRIVワーキンググループ、(geopriv@ietf.org)、ナディーヌ・アボット(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

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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" /> <タイトル> PIDF-LOのためのNENAのdataProviderスキーマ</タイトル> </ head> <body> <H1> NENA dataProviderのスキーマのための '提供ごと' PIDF-LOの</ H1> <H2> URN:IETF:のparams:XML:NS:PIDF:geopriv10:dataProviderの</ H2> <P> <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt"> RFC4119を参照してください。 </a>にします。</ p> </ body> </ html>このEND

A.1. dataProvider XML Schema

A.1。 dataProviderのXMLスキーマ

<?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>

<?xml version = "1.0" エンコード= "UTF-8"?> <! - XMLSPYのV5の相対で編集。パトリシアBluhm(HBFグループ)によって3 U(http://www.xmlspy.com) - > <XS:スキーマの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 = "資格" attributeFormDefault = "非修飾"> <XS:要素名= "ネーナ" タイプ= "TNS:DataProviderIDType" /> <XS:complexTypeの名= "DataProviderIDType"> <XS:注釈> <XS:ドキュメント> NENAは、位置情報を供給するサービスプロバイダの会社IDを登録</ XS:ドキュメント> </ XS:注釈> <XS:すべて> <XS:要素名= "DataProviderID" タイプ= "TNS:NENACompanyIDType" のminOccurs = "0" /> <XS:要素名= "TelURI" タイプ= "TNS:TelURI_24x7Type "minOccurs属性=" 0 "/> <XS:要素名=" URL "タイプ= "XS:anyURIの" minOccurs属性= "0"/> </ XS:すべて> </ XS:complexTypeの> <XS:単純型名=" NENACompanyIDType "> <XS:注釈> <XS:ドキュメント> NENAは、会社IDを登録</ XS:ドキュメント> </ XS:注釈> <XS:制限ベース=" XS:文字列 "> <XS:maxLengthの値=" 5 "/> </ XS:制限> </ XS:単純> <XS:単純型名=" TelURI_24x7Type "> <XS:注釈> <XS:ドキュメント>発信者の[位置データ]サービスプロバイダの24時間365日の電話URI。位置データの問題を解決するために、サービスプロバイダに連絡するために使用します。 。<:ドキュメント/ XS> </ XS:注釈> <XS:組合memberTypesの= "XS:anyURIの"> <XS:単純>利用できない値を列挙可能な値TN番号、

                               <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>

<XS:列挙値= "UNAVAILABLE" /> </ XS:制限> </ XS:単純> </ XS:ユニオン> </ XS:単純> </ XS:スキーマ>

Normative References

引用規格

[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、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]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット(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.、RFC 3851、2004年7月 "/多目的インターネットメール拡張(S / MIME)バージョン3.1メッセージ仕様を固定します"。

[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]レビンソン、E.、 "コンテンツIDとMessage-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.

、RFC 3565、2003年7月[8] Schaad、J.、 "高度暗号化標準(AES)暗号メッセージ構文(CMS)での暗号化アルゴリズムの使用"。

[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.

[9] Ramsdell、B.は、RFC 3850、2004年7月 "/多目的インターネットメール拡張(S / MIME)バージョン3.1証明書の処理を固定します"。

Informative References

参考文献

[10] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

[10]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、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]モリス、J.、マリガン、D.、およびJ.クエリャル、 "コアのプライバシー保護Geopriv場所オブジェクトについて"、進歩、2003年6月での作業。

[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.

[12]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。

[13] Peterson, J., "A Presence Architecture for the Distribution of Geopriv Location Objects", Work in Progress, February 20003.

[13]ピーターソン、J.、「Geopriv場所オブジェクトの分布のプレゼンスアーキテクチャ」、進歩2月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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、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の、 "オープン地理マークアップ言語(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.、マリガン、D.、モリス、J.、およびJ.ピーターソン、 "Geoprivプロトコルの脅威分析"、RFC 3694、2004年2月。

Author's Address

著者のアドレス

Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US

ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520米国

Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/

電話:+1 925/363から8720 Eメール:jon.peterson@neustar.biz URI:http://www.neustar.biz/

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2005).

著作権(C)インターネット協会(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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。