RFC4119 日本語訳
4119 A Presence-based GEOPRIV Location Object Format. J. Peterson. December 2005. (Format: TXT=53522 bytes) (Updated by RFC5139) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Peterson Request for Comments: 4119 NeuStar Category: Standards Track December 2005
コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 4119年のNeuStarカテゴリ: 標準化過程2005年12月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントは、インターネットの地理的な情報を運ぶためにオブジェクト形式について説明します。 この位置のオブジェクトはPresence情報Data Format(PIDF)を広げています。(Data Formatはプライバシー機密の存在情報を伝えるように設計されて、同様の特性を持っています)。
Peterson Standards Track [Page 1] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[1ページ]。
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. 序論…2 1.1. このドキュメントで中古のコンベンション…3 2. 位置のオブジェクト形式…4 2.1. 基線PIDF用法…4 2.2. 位置と用法規則のためのPIDFへの拡大…5 2.2.1. '位置インフォメーション'要素…5 2.2.2. '用法規則'要素…7 2.2.3. 'メソッド'要素…9 2.2.4. '提供された'要素…9 2.2.5. 図式定義…10 2.3. 例の位置のオブジェクト…14 3. 使用プロトコルでPIDFを運びます…15 4. PIDFを固定します…15 5. セキュリティ問題…17 6. IANA問題…17 6.1. 'メソッド'トークン…17 6.2. 提供された''Elements…18 6.3. つぼ:ietf:params:xml:ナノ秒:pidf:geopriv10のためのURN Sub-名前空間Registration…18 7. 承認…19A.付録: NENAは図式を提供しました…20 A.1dataProvider XML図式…21 標準の参照…22 有益な参照…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
その結果、必要性は、ユーザのプライバシーと公開好みを含んで、強い暗号のセキュリティによって保護されるオブジェクトの中に地理的な位置情報を伝えるために特定されました。 この問題が一般的問題との何らかの類似を持っている前の仕事[13]は見ました。
Peterson Standards Track [Page 2] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[2ページ]。
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.
存在がインターネットの情報であるとコミュニケートして、機密保護します。 存在、(定義されたコネ[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情報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個の基本要素。 しかしながら、このドキュメントはLocation Serversの必要性を収容して、どう完全なXMLベースのrulesetをPIDFに埋め込むことができたかを示しません。 他のプロトコル(HTTPなどの)が規則をRule HoldersとLocation Serversの間に動かすのに使用されて、完全なrulesetsが別々のドキュメントで定義されると思われます。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
Peterson Standards Track [Page 3] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[3ページ]。
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)は位置情報が説明する人、場所またはもの(REQ2.1)に名前の必要性を指定します。 PIDFには、そのような識別子が既にあります: あらゆるPIDFドキュメントには、ドキュメントが存在について説明する実体のURIを意味する'存在'要素の「実体」属性があります。 その結果、位置情報がPIDFドキュメントに含まれているなら、'存在'要素の「実体」属性におけるURIはその位置情報('presentity')の目標を示します。 一般に、「実体」属性におけるURIは[3]で定義された"pres"URI体系を使用します。 そのようなURIは「放-可能」匿名(REQ12あたりの)として機能できます。
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は任意にコミュニケーションのいくつかの手段でpresentityが届くことができるところにURIを提供する'接触'要素を含んでいます。 通常、'接触'要素の価値におけるURI体系はpresentityにどう達することができるかに関する何らかの感覚を与えます。 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は'状態'要素を含んでいます。(それは、義務的です)。 '状態'はpresentityのコミュニケーション気質(非常に広い用語: オープンかCLOSEDのどちらかの)について説明する'基本的な'任意の子供要素を含んでいます。 このドキュメントの目的には、'基本的な'状態が含まれるのは必要ではありません。 しかしながら、コミュニケーション気質がgeolocationを超えた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は'tuple'かさの要素を含んでいます。(それは、時間がたつにつれてこの情報への変化を追うことができて(存在の複数の通知が受信されているとき)、「イド」要素を使用して、唯一存在情報のセグメントを特定するように主張します)。 'タイムスタンプ'、'状態'、および'接触'は'tuple'の下で構成されます。
Peterson Standards Track [Page 4] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[4ページ]。
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.
複雑な要素が'geopriv'と呼ばれている状態で、このXML SchemaはPIDFの'状態'要素について敷衍しています。 geoprivの中でカプセル化される2つの主要な下位要素があります: 位置情報のためのもの、および用法規則のためのもの。 これらの下位要素の両方が、義務的であり、その後のセクションで説明されます。 'geopriv'の下のこれらの2つの下位要素を構成することによって、用法規則は明確に、明らかに位置情報に関連づけられます。
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.
伸展性(REQ1.4を見る)のために、図式で、いかなる他の下位要素も'geopriv'要素の下に現れます。 他の2つの任意の下位要素が本書では含まれています: 地理的な位置が決定していたメソッドを示すもの、および情報を提供した実体の明白な名称を許容するもの。
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つの'位置インフォメーション'要素を含まなければなりません。 '位置インフォメーション'要素は位置情報(REQ2.5あたりの)の1つ以上の塊から成ります。 位置情報(REQ2.6)の形式はインポートしているXML Schemaによって特定されます。(XML Schemaは問題の名前空間について説明します)。 'geopriv'要素を含むすべてのPIDFドキュメントが地理的な位置の形式に使用されるXML Schema(s)を示す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実装の相互運用性を確実にするために、すべての対応する実装がサポートする基線位置の形式を選択するのが必要です(REQ3.1を見てください)。 REQを満たす、2.5、.1、このドキュメントはGeography Markup Language(GML)3.0[15]がこの義務的な形式になるという(aはすべてのPIDFのために'geopriv'要素を支える実装を実装しなければなりません)仮定から働いています。
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は地理的なオブジェクト・タイプのすべての様式をモデル化する異常に徹底的で多能なシステムです、topologies、メタデータ、コーディネートしている基準方式、およびユニットの測定。 位置をサポートする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'は複雑な地理的な概念を言い表すことができますが、基本的なコーディネートしているポイントを最も一般的に使用されたケースに供給するのが非常に小さいマーク付けを必要とします。 様々な書式の記述(緯度/経度を含んでいると、位置情報は基づいた)がFeatureによってサポートされる、(.4が、7.4に.1を区分するのを見る、例のための[15])、ここに住んでいるもの:
Peterson Standards Track [Page 5] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[5ページ]。
urn:opengis:specification:gml:schema-xsd:feature:v3.0
つぼ:opengis:仕様: gml: 図式-xsd: 特徴: v3.0
Note that by importing the Feature schema, necessary GML baseline schemas are transitively imported.
Feature図式をインポートすることによって、必要なGML基線schemasが移行的にインポートされることに注意してください。
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.
また、複雑な特徴(目標に、特定の位置が有効である時のモデルtopologiesや多角形や方向やベクトル、時のしるしなどの)もGMLで利用可能ですが、追加schemasをインポートするのを必要であってください。 定義されるとしてのこのドキュメントによる基線相互運用性の目的のために、'feature.xsd'GML図式の唯一のサポートはREQUIREDです。
Implementations MAY support the civic location format (civicLoc) defined in Section 2.2.5. civicLoc provides the following elements:
都市の位置の形式(civicLoc)がセクション2.2.5civicLocで定義した実装5月のサポートは以下の要素を提供します:
+----------------------+----------------------+---------------------+ | 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 | |
+----------------------+----------------------+---------------------+ | ラベル| 記述| 例| +----------------------+----------------------+---------------------+ | 国| 国はそうです。| 米国| | | 特定されます。| | | | 2文字のISO3166| | | | コード。 | | | | | | | A1| 国家| ニューヨーク| | | 区画分譲地(| | | | | | | 状態、| 領域、州、県)| | | | | | | A2| カウンティー、教区、銃| キングのカウンティー| | | (JP), 地区(IN)| | | | | | | A3| 都市、郡区、shi| ニューヨーク| | | (JP) | | | | | | | A4| 都市の分割| マンハッタン| | | 自治区、都市| | | | 地区、区、キャベツ| | | | (JP) | | | | | | | A5| 近所、ブロック| モーニングサイド・ハイツ| | | | | | A6| 通り| ブロードウェイ| | | | | | PRD| 主な通り| N、W| | | 方向| | | | | | | さや| 引きずっている通り| SW| | | 接尾語| |
Peterson Standards Track [Page 6] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[6ページ]。
| | | | | 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 | +----------------------+----------------------+---------------------+
| | | | | 通り| 通り接尾語| アベニュー、プラッツ| | | | 通り| | | | | | HNO| 番地| 123 | | | 数値部分専用。 | | | | | | | HNS| 番地接尾語| A、1/2| | | | | | LMK| 目印か虚栄| 低い図書館| | | アドレス| | | | | | | LOC| 追加位置| 部屋543| | | 情報| | | | | | | FLR| 床| 5 | | | | | | NAM| (住居、| ジョーのBarbershop| | | ビジネスまたはオフィス| | | | 占有者)を命名してください。| | | | | | | PC| 郵便番号| 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.
本書では定義されたGML3.0の地理的な情報形式要素か位置の形式要素のどちらか('civicLoc')は'位置インフォメーション'要素に現れるかもしれません。 また、両方が同じ'位置インフォメーション'要素で使用されるかもしれません。 概要では、この仕様による対応することの実装でGML3.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オブジェクトのための方針要件は決定的に完成しませんでした。 しかしながら、'用法規則'要素は、GEOPRIV方針要件[11]ドキュメントのREQ2.8と要件を満たすために存在しています。 それぞれの'geopriv'要素が1つの'用法規則'要素を含まなければならない、Rule
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
方針要件ドキュメント(セクション3.1)に従って、彼らのlifecycle(GeneratorからRecipientまでの)中にLocation Objectsで表現できる必要がある3つの分野があります: 「再-トランスミッション」を制限する1つの分野、保有を制限するもの、および外部のrulesetsの参照を含むもの。 それらの3つの分野がそうです。
Peterson Standards Track [Page 7] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[7ページ]。
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つの要素で、例示されます。 4番目の要素は人間読み込み可能な方針指示にジェネリックスペースを提供します。 これらの分野のどれかはLocation Object'用法規則'要素に存在しているかもしれません。 なにも必要に必要ではありません。
'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.
'「再-トランスミッション」によって許容される': この要素の価値が'いいえ'であるときに、このLocation ObjectのRecipientが同封のLocation情報、または全体でオブジェクトを共有することが許可されません、相手と共に。 この要素の価値が'はい'であるときに、このLocationを分配するのは受入れられます(それと反対にバンドの既存の出ている協定か義務を禁じます)。 デフォルトで、'いいえ'であると値を思わなければなりません。 Rule Makerが好みを全く指定しないなら、実装は'いいえ'の値でこの分野を含まなければなりません。
'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.
'保有で期限が切れます': この分野はRecipientがもう位置情報を持っていることが許可されていて、それがLocation Objectをカプセル化することである絶対期日を指定します。 時間がこの分野のそばで指定するまでしか、両方が保有されないかもしれません。 デフォルトで、PIDFドキュメントの'タイムスタンプ'要素から24時間であると値を思わなければなりません、存在しているなら。 また、'タイムスタンプ'要素も存在していないなら、Location ObjectがLocation Recipientによって受け取られる時から24時間であると値を思わなければなりません。 いつが既に、通ったか。中の値である、要素を'保有で吐き出す'、Location RecipientはLocation Objectを受けて、Recipientはすぐに、Location Objectを捨てなければなりません。
'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-参照': この分野はどこでこのオブジェクトに関連する方針の、よりふくよかなrulesetを見つけることができるかを示すURIを含んでいます。 このURI SHOULDはHTTPS URI体系を使用します。 そして、そうするなら、これらの規則を保持するサーバはこれらの規則にアクセスするどんな試みも認証しなければなりません。 用法規則自体はTargetかRule Makerに関する個人情報を明かすかもしれません。 あるいはまた、URIはCID URI体系[7]を使用するかもしれません、その場合、それがLocation Objectと共に使用プロトコルによって運ばれたMIME本体を指示しなければなりません。 Rulesetsは暗号化されていて、MIMEボディーSHOULDとして運んで、Rule Makerで署名しました。 未署名のrulesets SHOULD、Location ServersかLocation Recipientsによって光栄に思われないでください。 Location Objectsのクリエイターが承認失敗をもたらすネットワークルックアップを避けるためにCIDによって参照をつけられた暗号化された外部のMIME本体にHTTPSベースのruleset参照を入れるかもしれないことに注意してください。 このように、彼らがMIME本体を解読することができないと、外部のMIME本体を解読することができないLocation Objectの受取人はHTTPS URIを学ばないでしょう。
Peterson Standards Track [Page 8] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[8ページ]。
'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.
'注意良い': この分野はさらなるジェネリックプライバシー指示を含む1ブロックのテキストを含んでいます。 これらの指示が人間読み込み可能であることを意図する、単に、どんなオートマトンによっても処理されないように。
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>
提供された><がテストする<: ></提供されたゲーム>West5</テスト: ゲーム>。
Values for the 'provided-by' element MUST be IANA-registered XML namespaces; see Section 6.2 for more information.
提供された''要素のための値はIANAによって登録されたXML名前空間でなければなりません。 詳しい情報に関してセクション6.2を見てください。
Peterson Standards Track [Page 9] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置のオブジェクト2005年12月にRFC4119を追跡します[9ページ]。
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.
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.
2.2.5. Schema Definitions
2.2.5. Schema Definitions
Note that the XML namespace [4] for this extension to PIDF contains a version number 1.0 (as per REQ 2.10).
Note that the XML namespace [4] for this extension to PIDF contains a version number 1.0 (as per REQ 2.10).
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<?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" />
<xs:import namespace= "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" />
<!-- This import brings in the XML language attribute xml:lang-->
<!-- This import brings in the XML language attribute xml:lang-->
Peterson Standards Track [Page 10] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 10] RFC 4119 GEOPRIV Location Object December 2005
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<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: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="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="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="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:complexType name="locProvidedBy"> <xs:sequence> <xs:any namespace="##other" processContents="skip" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
</xs:schema>
</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,
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,
Peterson Standards Track [Page 11] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 11] RFC 4119 GEOPRIV Location Object December 2005
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.
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" 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"/>
<!-- 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="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:complexType name="notewell"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute ref="xml:lang" /> </xs:extension> </xs:simpleContent> </xs:complexType>
</xs:schema>
</xs:schema>
The following schema is a trivial representation of civic location that MAY be implemented by entities compliant with this specification.
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"
<?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"
Peterson Standards Track [Page 12] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 12] RFC 4119 GEOPRIV Location Object December 2005
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
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: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>
</xs:schema>
Peterson Standards Track [Page 13] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 13] RFC 4119 GEOPRIV Location Object December 2005
2.3. Example Location Objects
2.3. Example Location Objects
Note that these examples show PIDF documents without any MIME headers or security applied to them (see Section 4 below).
Note that these examples show PIDF documents without any MIME headers or security applied to them (see Section 4 below).
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.
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 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" 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.
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 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" 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>
Peterson Standards Track [Page 14] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 14] RFC 4119 GEOPRIV Location Object December 2005
<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: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>
3. Carrying PIDF in a Using Protocol
3. Carrying PIDF in a Using Protocol
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'.
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'.
Further specification of the behavior of using protocols (including subscribing to or requesting presence information) is outside the scope of this document.
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. Securing 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.
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.
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.
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.
Peterson Standards Track [Page 15] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 15] RFC 4119 GEOPRIV Location Object December 2005
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] 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.
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.
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.
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 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.
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.
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.
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
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
Peterson Standards Track [Page 16] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 16] RFC 4119 GEOPRIV Location Object December 2005
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
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).
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.
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.
5. Security Considerations
5. Security Considerations
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).
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).
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.
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.
Security requirements associated with using protocols (including authentication of subscribers to geographical information, etc.) are outside the scope of this document.
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 Considerations
6.1. 'method' Tokens
6.1. 'method' Tokens
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.
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.
This section pre-registers 7 new 'method' tokens associated with the 'method' element described above in Section 2.2.3:
This section pre-registers 7 new 'method' tokens associated with the 'method' element described above in Section 2.2.3:
Peterson Standards Track [Page 17] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 17] RFC 4119 GEOPRIV Location Object December 2005
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: 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)
6.2. 'provided-by' Elements
6.2. 'provided-by' Elements
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.
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.
This document pre-registers a single XML namespace for 'provided-by', which is given in Appendix A.
This document pre-registers a single XML namespace for 'provided-by', which is given in Appendix A.
6.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10
6.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10
This section registers a new XML namespace, as per the guidelines in [4].
This section registers a new XML namespace, as per the guidelines in [4].
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: 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:
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-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">
Peterson Standards Track [Page 18] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 18] RFC 4119 GEOPRIV Location Object December 2005
RFC4119</a>.</p>
</body>
</html>
END
RFC4119</a>.</p> </body> </html> END
7. Acknowledgements
7. Acknowledgements
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.
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.
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.
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.
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 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.
Peterson Standards Track [Page 19] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 19] RFC 4119 GEOPRIV Location Object December 2005
A. Appendix: NENA Provided-By Schema
A. Appendix: NENA Provided-By Schema
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.
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.
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.
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.
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: 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:
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-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
Peterson Standards Track [Page 20] RFC 4119 GEOPRIV Location Object December 2005
Peterson Standards Track [Page 20] RFC 4119 GEOPRIV Location Object December 2005
A.1. dataProvider XML Schema
A.1. dataProvider XML Schema
<?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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><!--XMLSPY v5 relと共に編集されます。 3 パトリシアBluhm(HBF Group)によるU( http://www.xmlspy.com )--「適切である」" http://www.w3.org/2001/XMLSchema "><xs: 図式targetNamespace=「つぼ:ietf:params:xml:ナノ秒:pidf:geopriv10: dataProvider」xmlns: tns=「つぼ:ietf:params:xml:ナノ秒:pidf:geopriv10: dataProvider」xmlns: xs=elementFormDefault=attributeFormDefault=、「資格のなさ、「><xs:」; 要素名前="nena"タイプ=「tns: DataProviderIDType」/><はxsされます: complexTypeが=を命名する、「DataProviderIDType、「><xs: 注釈><xs: ドキュメンテーション>NENAは位置情報</xsを供給するService Providerのために会社IDを登録しました」; ドキュメンテーション></xs: 注釈><xs: すべての><xs: 要素名=の"DataProviderID"が=「tns: NENACompanyIDType」minOccurs=をタイプする、「0インチ/>の<はxsされます: 「tns: TelURI_24x7Type」要素名前="TelURI"タイプ=minOccurs=「0インチ/>の<は以下をxsします」; 要素名前=「URL」タイプが「xs: anyURI」minOccurs=と等しい、「0インチ/>の</xs: すべての></xs: complexType><xs: simpleTypeが=を命名する、「NENACompanyIDType、「><xs: 注釈><xs: ドキュメンテーション>NENAは会社IDを登録しました」; </xs: ドキュメンテーション></xs: 注釈><xs: 制限ベース=「xs: ストリング「><xs: maxLength値=」5インチ/></xs: 制限></」xs: simpleType><xs: simpleTypeが=を命名する、「TelURI_24x7Type、「><xs: 注釈><xs: 訪問者[位置のデータ]のサービスプロバイダーのためのドキュメンテーション>24x7Tel URI。」 位置のデータに関する問題を解決するためにサービスプロバイダーに連絡するのに使用されるために。 列挙されて、テネシーが付番する可能な値は利用可能でないいつを評価するか。</xs: ドキュメンテーション></xs: 注釈><はxsされます: 組合memberTypes=、「xs: anyURI、「><xs: simpleType>」
<xs:restriction base="xs:string">
<xs:maxLength value="10"/>
<xs:enumeration value="NOT FOUND"/>
<xs: 制限ベース=「xs: 10インチ/>の「><xs: maxLength値=」<xsを結んでください: 列挙値は"NOT FOUND"/>と等しいです」。
Peterson Standards Track [Page 21] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置の物の2005年12月にRFC4119を追跡します[21ページ]。
<xs:enumeration value="UNAVAILABLE"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:schema>
<xs: 列挙値の=「入手できません、な」/></xs: 制限></xs: simpleType></xs: 組合></xs: simpleType></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のキーワード」、BCP14、RFC2119、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.、Bateman、A.、カー、W.、およびJ.ピーターソン、「存在インフォメーション・データは(PIDF)をフォーマットします」、RFC3863、2004年8月。
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
October 2003.
[3] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2003年10月。
[4] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January
2004.
[4] 食事、M.、「IETF XML登録」、RFC3688、BCP81、2004年1月。
[5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[5]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[6]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[7] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[7] レヴィンソン、E.、「コンテントIDとMessage ID Uniform Resource Locator」、RFC2392、1998年8月。
[8] Schaad, J., "Use of the Advanced Encryption Standard (AES)
Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC
3565, July 2003.
[8]Schaad、J.、「暗号のメッセージ構文(cm)におけるエー・イー・エス(AES)暗号化アルゴリズムの使用」、RFC3565(2003年7月)。
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[9]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書取り扱い」、RFC3850、2004年7月。
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要件」、RFC3693、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.クエリャルが進歩、2003年6月に働くのを「Geopriv位置のためのコアプライバシー保護は反対します」。
Peterson Standards Track [Page 22] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置の物の2005年12月にRFC4119を追跡します[22ページ]。
[12] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
2000年2月の[12] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」(RFC3261)は2002がそうするかもしれません。
[15] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC 02-023r4, January 2003,
<http://www.opengeospatial.org/specs/?page=specs>.
[15]OpenGIS、「開いている地理学マークアップ言語(GML)実現仕様」OGC02-023r4、2003年1月、<http://www.opengeospatial.org/specs/--ページは仕様>と等しいです。
[16] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004.
2004年2月の[16]DanleyとM.とマリガンとD.とモリス、J.とJ.ピーターソン、「Geoprivプロトコルの脅威分析」RFC3694。
Author's Address
作者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
Peterson Standards Track [Page 23] RFC 4119 GEOPRIV Location Object December 2005
ピーターソンStandardsはGEOPRIV位置の物の2005年12月にRFC4119を追跡します[23ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Peterson Standards Track [Page 24]
ピーターソン標準化過程[24ページ]
一覧
スポンサーリンク
