RFC 6447 - Filtering Location Notifications in the Session Initiation Protocol (SIP) 日本語訳

URL : https://tools.ietf.org/html/rfc6447
タイトル : RFC 6447 - セッション開始プロトコル（SIP）におけるフィルタリングの場所の通知
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                           R. Mahy
Request for Comments: 6447                                    Individual
Category: Standards Track                                       B. Rosen
ISSN: 2070-1721                                                  NeuStar
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                            January 2012

                  Filtering Location Notifications in
                 the Session Initiation Protocol (SIP)

Abstract

抽象

This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO).

この文書では、魅力的なイベントに非同期の場所の通知を制限するフィルタを記述します。これらのフィルタは、RFC 4661の拡張として設計されたイベント通知フィルタリングのためのXMLベースのフォーマット、およびRFC 3856に基づいて、SIPプレゼンス・イベント・パッケージされています。得られた位置情報は、プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）に包まれた既存の場所の形式で搬送されます。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6447.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6447で取得することができます。

著作権表示

著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Filter Definitions . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Movement . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Speed Changes  . . . . . . . . . . . . . . . . . . . . . .  5
     3.3.  Element Value Changes  . . . . . . . . . . . . . . . . . .  5
     3.4.  Entering or Exiting a Region . . . . . . . . . . . . . . .  8
     3.5.  Location Type  . . . . . . . . . . . . . . . . . . . . . . 10
     3.6.  Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12
   4.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16
     6.2.  Schema Registration for location-filter  . . . . . . . . . 16
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18

1. Introduction

1. はじめに

Conveying location information encapsulated with a Presence Information Data Format Location Object (PIDF-LO) [RFC4119] document within SIP is described in [SIP-LOC]. An alternative signaling approach to location conveyance, which uses asynchronous communication, is available with the SIP event notification mechanisms (see RFC 3265 [RFC3265]). This approach conveys location information in PIDF-LO format using the presence event package [RFC3856]. This document focuses on the event notification paradigm.

プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）でカプセル化された位置情報を伝達する[RFC4119] SIP内の文書は、[SIP-LOC]に記載されています。非同期通信を使用して位置搬送の代替シグナリングアプローチは、SIPイベント通知機構で利用可能である（RFC 3265 [RFC3265]を参照）。このアプローチは、プレゼンス・イベント・パッケージ[RFC3856]を使用してPIDF-LOのフォーマットで位置情報を伝えます。この文書では、イベント通知のパラダイムに焦点を当てています。

Determining when to send event notifications with location information is technically more challenging than deciding when to send other categories of notifications, since location may be measured as a continuous gradient. Unlike notifications using discrete-valued quantities, it is difficult to know when a change in location is sufficiently large to warrant a notification. Event notifications [RFC3265] can be used with filters (see RFC 4661 [RFC4661]) that allow the number of notifications to be reduced. The mechanism described in this document defines an extension to RFC 4661 [RFC4661], which limits location notification to events that are of relevance to the subscriber. These filters persist until they are replaced with a newer filter or until the subscription itself is terminated.

位置は、連続勾配として測定することができるので、位置情報にイベント通知を送信するときに決定することは、通知の他のカテゴリを送信するときに決定するよりも技術的に困難です。離散値の量を用いて通知とは異なり、場所の変更が通知を保証するのに十分に大きい場合に知ることは困難です。イベント通知[RFC3265]は通知の数を減らすことができるようにすること（RFC 4661 [RFC4661]を参照）フィルタを使用することができます。本書で説明されたメカニズムは、加入者に関連性のあるイベントに位置通知を制限RFC 4661 [RFC4661]の拡張機能を定義します。彼らは、新しいフィルタまたはサブスクリプション自体が終了されるまで交換されるまで、これらのフィルタは保持されます。

The frequency of notifications necessary for various geographic location applications varies dramatically. The subscriber should be able to get asynchronous notifications with appropriate frequency and granularity, without being flooded with a large number of notifications that are not important to the application.

様々な地理的位置の用途のために必要な通知の頻度が劇的に変化します。加入者がアプリケーションにとって重要でない通知の多数が殺到されることなく、適切な周波数および粒度で非同期通知を得ることができる必要があります。

This document defines new event filters and describes others using existing mechanisms that may be relevant to a subscriber in the context of location filtering. Based on the functionality defined in this document, notifications can be provided in the following cases:

この文書は、新しいイベントフィルタを定義し、位置フィルタリングのコンテキスト内の加入者に関連し得る既存のメカニズムを使用して他人が記載されています。この文書で定義された機能に基づいて、通知は次の場合に提供することができます。

1. the Target moves more than a specified distance since the last notification (see Section 3.1).

1.ターゲットが最後の通知以降の所定距離以上を移動させる（セクション3.1を参照）。

2. the Target exceeds a specified speed (see Section 3.2).

2.ターゲット（セクション3.2を参照）所定速度を超えています。

3. the Target enters or exits a 2-dimensional region, described by a circle or a polygon (see Section 3.4).

3.ターゲット（セクション3.4を参照）円形又は多角形によって記述される2次元領域に入るまたは出ます。

4. one or more of the values of the specified civic location have changed for the location of the Target (see Section 3.3). For example, the value of the civic address '<A1>' element has changed from 'California' to 'Nevada'.

4.指定された市民の位置の値のうちの1つ以上は（セクション3.3を参照）ターゲットの位置については変更されています。例えば、市民のアドレス「<A1>」要素の値は「ネバダ」に「カリフォルニア」から変更されました。

5. the type of location information requested (see Section 3.5) changes, for example, from civic to geodetic location or vice versa.

前記要求された位置情報（セクション3.5を参照）変更、例えば、市民からの測地位置へ、またはその逆のタイプ。

6. a certain amount of time passes (see Section 3.6).

6時間の一定量（セクション3.6を参照）を通過します。

2. Terminology

2.用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

This document reuses terminology from [RFC6280].

この文書では、[RFC6280]から用語を再利用します。

3. Filter Definitions

3.フィルタ定義

This specification builds on a number of other specifications, as noted in Section 1. In order to reduce the number of options (and thereby decrease the chance of interoperability problems), the functionality described in the following sub-sections of [RFC4661] MUST be implemented: the <ns-bindings> element (see Section 3.3 of [RFC4661]); the <filter> element (Section 3.4 of [RFC4661]); and the <trigger> element (Section 3.6 of [RFC4661]), except for the <added> and <removed> sub-elements.

オプションの数を減らす（およびそれによって相互運用性の問題の可能性を減少させる）ために、第1節で述べたように、本明細書は、他の仕様の数に基づいて構築、[RFC4661]の次のサブセクションで説明された機能性でなければなりません実施<NS-バインディング>要素（[RFC4661]のセクション3.3を参照）。 <フィルター>要素（[RFC4661]のセクション3.4）。そして<トリガー>要素（[RFC4661]のセクション3.6）、<追加>と<除去>サブ要素を除きます。

3.1. Movement

3.1. 移動

The <moved> element MUST contain a value in meters indicating the minimum distance that the resource must have moved from the location of the resource since the last notification was sent in order to trigger this event. The distance MUST be measured in meters absolutely from the point of the last notification, and must include vertical movement. The <moved> element MUST NOT appear more than once as a child element of the <filter> element.

<移動>要素は、最後の通知がこのイベントをトリガするために送信されたため、リソースがリソースの位置から移動しておく必要があり、最小距離を示すメーターの値を含まなければなりません。距離は絶対最後の通知の時点からメートル単位で測定しなければならない、及び垂直方向の移動を含まなければなりません。 <移動>要素は、<フィルタ>要素の子要素として複数回現れてはなりません。

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns:lf="urn:ietf:params:xml:ns:location-filter"> <filter id="123" uri="sip:presentity@example.com"> <trigger> <lf:moved>300</lf:moved> </trigger> </filter> </filter-set>

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター" のxmlns：LF = "壷：IETF：のparams：XML ：NS：位置フィルタ "> <フィルタID =" 123" URI = "SIP：presentity@example.com"> <トリガー> <LF：移動> 300 </ LF：移動> </トリガ> </フィルタ> </フィルタセット>

Figure 1: Movement Filter Example

図1：運動フィルタの例

3.2. Speed Changes

3.2. スピードの変更

Speed changes can be filtered by combining functionality from RFC 4661 with the PIDF-LO extensions for spatial orientation, speed, heading, and acceleration defined in [RFC5962]. The value of the <speed> element from [RFC5962] MUST be defined in meters per second. Note that the condition could be met by a change in any axis, including altitude.

速度の変更は、[RFC5962]で定義された空間的な向き、速度、方位、および加速のためのPIDF-LOの拡張子を持つRFC 4661の機能を組み合わせることによって濾過することができます。 [RFC5962]から<速度>要素の値は、メートル毎秒で定義されなければなりません。条件は高度を含む、任意の軸の変化によって満たされることに留意されたいです。

Figure 2 shows an example for a trigger that fires when the speed of the Target changes by 3 meters per second.

図2は、火災場合秒当たり3メートルのターゲット変化の速度トリガの例を示しています。

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <ns-bindings> <ns-binding prefix="dyn" urn="urn:ietf:params:xml:schema:pidf:dynamic"/> </ns-bindings> <filter id="123" uri="sip:presentity@example.com"> <trigger> <changed by="3"> //dyn:speed </changed> </trigger> </filter> </filter-set>

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター"> <NS-バインディング> <プレフィックスをNS-結合= "DYN" URN = "URN：IETF：paramsは：XML：スキーマ：PIDF：ダイナミック" /> </ NS-バインディング> <フィルタID = "123" URI = "SIP：presentity@example.com"> <トリガー>速度</変更> </トリガ> </フィルタ> </フィルタセット>：// DYN <= "3" によって変更>

Figure 2: Speed Change Example

図2：速度変更例

An implementation MUST support <ns-bindings> to replace the namespace prefix. The XPath expression MUST start with a '//' followed by a single element. No other form of XPath expression is supported. The <changed> element comes with a few attributes but only the 'by' attribute MUST be implemented by this specification.

実装は、名前空間接頭辞を置き換えるために、<NS-バインディング>サポートしなければなりません。 XPath式は、「//」一要素に続いて開始する必要があります。 XPath式の他の形式はサポートされていません。 <変更>要素は、この仕様で実装しなければならないいくつかの属性だけ「で」属性が付属しています。

3.3. Element Value Changes

3.3. 要素値の変更

Changes in values, for example related to civic location information, is provided by the base functionality offered with RFC 4661 utilizing the <changed> element.

値の変化は、市民の位置情報に関連する、例えば、RFC 4661 <変更>要素を利用して提供される基本機能によって提供されます。

The following example illustrates a filter that triggers when the Target's location changes from 'FR' (France) to some other country.

次の例では、「FR」（フランス）からいくつかの他の国へのときに、ターゲットの位置の変更をトリガーするフィルタを示しています。

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター"> <NS-バインディング> <プレフィックスをNS-結合= "CA" URN = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10：civicAddr" /> </ NS-バインディング> <フィルタID = "123" URI = "SIP：presentity@example.com"> <国</変更> </トリガー> </フィルタ> </フィルタリング設定>：トリガーは、<= "FR"> // CAから変更します>

Figure 3: Element Value Change Example (Country Change)

図3：要素の値の変更例（国を変更）

At times when it is desirable to know if any one element of a list of CAtypes changes, then they have to be put into separate <changes> filters to ensure the subscriber is notified when any of the element values change. Figure 4 shows such an example that illustrates the difference.

それはCAtypes変更のリストのいずれかの要素かどうかを知ることが望ましいとき時には、それらは要素の値のいずれかが変更されたときに、加入者に通知されていることを確認するために、別の<変化>フィルターに入れなければなりません。図4は、差を示すような例を示しています。

(A change in value of ANY of the five tokens triggers an event.)

（5つのトークンのいずれかの値の変化は、イベントをトリガします。）

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <ns-bindings> <ns-binding prefix="ca" urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/> </ns-bindings> <filter id="123" uri="sip:presentity@example.com"> <trigger> <changed>//ca:country</changed> </trigger> <trigger> <changed>//ca:A1</changed> </trigger> <trigger> <changed>//ca:A2</changed> </trigger> <trigger> <changed>//ca:A3</changed> </trigger> <trigger> <changed>//ca:PC</changed> </trigger> </filter> </filter-set>

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター"> <NS-バインディング> <プレフィックスをNS-結合= "CA" URN = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10：civicAddr" /> </ NS-バインディング> <フィルタID = "123" URI = "SIP：presentity@example.com"> <トリガー> <> // CAを変更：国</変更> </トリガー> <トリガー> <変更> // CA：A1 </変更> </トリガー> <トリガー> <変更> // CA：A2 </変更> </トリガー> <トリガー> <変更> // CA：A3 </> </トリガ変更> <トリガー> <変更> // CA：PC </変更> </トリガー> </フィルタ> </フィルタ設定>

Figure 4: Element Value Change Example

図4：要素値の変更例

Finally, Figure 5 shows an example where a notification is sent when the civic address tokens A3 and PC change (BOTH elements must change in order to let the <trigger> element evaluate to TRUE).

最後に、図5は、市民のアドレスA3とPCの変化が（両方の要素が<トリガー>要素がTRUEに評価させるために変更しなければならない）トークンときに通知が送信される例を示しています。

(Only a change in BOTH tokens triggers an event.)

（BOTHトークンの変化だけがイベントをトリガします。）

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター"> <NS-バインディング> <プレフィックスをNS-結合= "CA" URN = "URN：IETF：paramsは：XML：NS：PIDF：geopriv10：civicAddr" /> </ NS-バインディング> <フィルタID = "123" URI = "SIP：presentity@example.com"> <トリガーは、<> // CAを変更>：A3 </変更> <変更> // CA：PC </変更> </トリガー> </フィルタ> </フィルタリング設定>

Figure 5: Element Value Change Example

図5：要素値の変更例

Note: The civic address tokens country, A1, A2, ..., A6 are hierarchical. It is likely that a change in one civic address token therefore leads to changes of tokens lower in the hierarchy, e.g., a change in A3 ('city or town') may cause a change in A4, A5, and A6.

注意：市民のアドレストークンの国を、A1、A2、...、A6は階層構造になっています。トークンのため、1つの市民アドレスの変更は、階層の下位トークンの変化につながる可能性がある、例えば、A3（ '市や町）の変化は、A4、A5、およびA6の変化を引き起こす可能性があります。

An implementation MUST support <ns-bindings> to replace the namespace prefix. The XPath expression MUST start with a '//' followed by a single element. No other form of XPath expression is supported. No other variant is supported. The <changed> element comes with a few attributes and the 'by', 'to', and 'from' attribute MUST be implemented to support this specification.

実装は、名前空間接頭辞を置き換えるために、<NS-バインディング>サポートしなければなりません。 XPath式は、「//」一要素に続いて開始する必要があります。 XPath式の他の形式はサポートされていません。他のバリアントがサポートされていません。 <変更>要素は、属性がこの仕様をサポートするために実装しなければならない「から」いくつかの属性と「は」、「から」が付属しており、。

3.4. Entering or Exiting a Region

3.4. 領域に入るか、終了

The <enterOrExit> condition is satisfied when the Target enters or exits a 2-dimensional region described by a polygon (as defined in Section 5.2.2 of [RFC5491]) or a circle (as defined in Section 5.2.3 of [RFC5491]). The <enterOrExit> element MUST contain either a polygon or a circle as a child element. The <enterOrExit> element MUST NOT have more than one polygon and/or circle.

<enterOrExit>条件ターゲットポリゴン（[RFC5491]のセクション5.2.2で定義されるように）または円形（によって記述2次元領域に入るまたは出るとき、[RFC5491]のセクション5.2.3で定義されるように満たされています）。 <enterOrExit>要素は、ポリゴンや子要素として円のいずれかを含まなければなりません。 <enterOrExit>要素は、複数の多角形および/または円を持ってはいけません。

If the Target was previously outside the region, the notifier sends a notification when the Target's location is within the region with at least 50% confidence. Similarly, when a Target starts within the region, a notification is sent when the Target's location moves outside the region with at least 50% confidence.

ターゲット領域の外側に以前にあった場合、通知は、ターゲットの位置が少なくとも50％の信頼度で領域内にある通知を送信します。ターゲット領域内で開始するとき、ターゲットの位置は、少なくとも50％の信頼度で領域外に移動したとき、同様に、通知が送信されます。

Note that having 50% confidence that the Target is inside the area does not correspond to 50% outside. The confidence that the location is within the region, plus the confidence that the location is outside the region is limited to the confidence of the location. The total confidence depends on the confidence in the location, which is always less than 100% (95% is recommended in [RFC5491]). The benefit of this is that notifications are naturally limited: small movements (relative to the uncertainty of the location) at the borders of the region do not trigger notifications.

対象エリア内にあることを50％の信頼度を有する外側50％に対応していないことに留意されたいです。位置が領域内である信頼度、プラス位置が領域外であると確信は、位置の信頼度に制限されます。合計信頼度が常に100％未満である位置の信頼に依存する（95％が[RFC5491]で推奨されています）。これの利点は、通知が自然に制限されることである。領域の境界における小さな動き（位置の不確実性に対しては）通知をトリガしません。

Figure 6 shows filter examples whereby a notification is sent when the Target enters or exits an area described by a circle, and Figure 7 describes an area using a polygon.

図6は、ターゲットが入るか円で説明エリアを出て、そして図7は、ポリゴンを使用して領域を記述するときに通知が送信されるフィルタの例を示します。

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns:lf="urn:ietf:params:xml:ns:location-filter" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0">

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター" のxmlns：LF = "壷：IETF：のparams：XML ：NS：位置フィルタ」のxmlns：GML = "http://www.opengis.net/gml" のxmlns：GS = "http://www.opengis.net/pidflo/1.0">

<フィルタID = "123" URI = "SIP：presentity@example.com"> <トリガー> <LF：enterOrExit> <GS：サークルsrsName = "URN：OGC：DEF：CRS：EPSG :: 4326"> <GML ：POS> 42.5463 -73.2512 </ GML：POS> <GS：半径UOM = "URN：OGC：DEF：UOM：EPSG :: 9001"> 850.24 </ gsは：半径> </ GS：サークル> </ LF： enterOrExit> </トリガー> </フィルタ> </フィルタリング設定>

Figure 6: <enterOrExit> Circle Filter Example

図6：<enterOrExit>サークルフィルタの例

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns:lf="urn:ietf:params:xml:ns:location-filter" xmlns:gml="http://www.opengis.net/gml">

<フィルタID = "123" URI = "SIP：presentity@example.com"> <トリガー> <LF：enterOrExit> <GML：ポリゴンsrsNameは= "URN：OGC：DEF：CRS：EPSG :: 4326"> <GML ：外装> <GML：リニアリング> <GML：POS> 43311 73 422 </ GML：！POS> < - A - > <GML：POS> 43111 73 322 </ GML：！POS> < - F - > <GML：POS> 43111 73 222 </ GML：POS> < - E - > <GML：POS> 43311 73 122 </ GML：POS> < - D - > <GML：POS > 43411 73 222 </ GML：POS> < - C - > <GML：POS> 43411 73 322 </ GML：POS> < - B - > <GML：POS> 43311 73 422 </ GML：！POS> < - A - > </ GML：リニアリング> </ GML：外装> </ GML：ポリゴン> </ LF：enterOrExit> </トリガー> </フィルタ> </フィルタリング設定>

Figure 7: <enterOrExit> Polygon Filter Example

図7：<enterOrExit>ポリゴンフィルタの例

3.5. Location Type

3.5. 場所の種類

The <locationType> element MAY be included as a child element of the <what> element. It contains a list of location information types that are requested by the subscriber. The following list describes the possible values:

<locationType>要素は、<何を>要素の子要素として含まれてもよいです。これは、加入者が要求された位置情報タイプのリストが含まれています。以下のリストは、可能な値を示します。

any: The Notifier SHOULD attempt to provide location information in all forms available to it.

いかなる：Notifierは、それが利用可能なあらゆる形態での位置情報を提供しようとすべきです。

geodetic: The Notifier SHOULD return a location by value in the form of a geodetic location.

測地：Notifierが測地位置の形で値によって位置を返すべきです。

civic: The Notifier SHOULD return a location by value in the form of a civic address.

市民：Notifierは市民アドレスの形式で値によって位置を返すべきです。

The Notifier SHOULD return the requested location type or types. The location types the Notifier returns also depends on the setting of the optional 'exact' attribute. If the 'exact' attribute is set to "true", then the Notifier MUST return either the requested location type or no location information. The 'exact' attribute does not apply (is ignored) for a request for a location type of "any".

Notifierは要求された場所の種類やタイプを返すべきです。 Notifierはまた返す場所の種類は、オプションの「正確な」属性の設定に依存します。「正確な」属性が「真」に設定されている場合、Notifierは要求された場所の種類、あるいは全く位置情報のいずれかを返さなければなりません。「正確な」属性は、「任意の」のロケーションタイプの要求のために（無視される）は適用されません。

In the case of a request for specific locationType(s) and the 'exact' attribute is "false", the Notifier MAY provide additional location types, or it MAY provide alternative types if the request cannot be satisfied for a requested location type.

特定locationType（S）のための要求の場合と「正確な」属性が「偽」であり、通知は、追加の場所の種類を提供してもよいし、要求は要求された位置タイプの満足できない場合には別のタイプを提供することができます。

If the <locationType> element is absent, a value of "any" MUST be assumed as the default.

<locationType>要素が存在しない場合、「任意」の値は、デフォルトとして想定されなければなりません。

The Notifier SHOULD provide civic and geodetic location information in the response in the same order in which they were included in the "locationType" element in the request, if both were explicitly requested. Indeed, the primary advantage of including specific location types in a request when the 'exact' attribute is set to "false" is to ensure that one receives the available locations in a specific order. For example, a subscription for "civic" (with the 'exact' attribute set to "false") could yield any of the following location types in the response:

Notifierは、両方が明示的に要求された場合、それらは、リクエスト中の「locationType」要素に含まれていたのと同じ順序で応答して市民と測地位置情報を提供すべきです。実際、「正確な」属性は「偽」に設定されている要求内の特定の場所の種類を含めての主な利点は、1つの特定のために利用可能な場所を受け取る保証することです。例えば、（「偽」に設定し「正確な」属性を持つ）「市民」のサブスクリプションは、応答内の次の場所の種類のいずれかをもたらすことができます：

o civic

市民O

o civic, geodetic

O市民、測地

o geodetic (only if civic is not available)

O測地（市民が利用できない場合のみ）

The default value of "false" for the 'exact' attribute allows the Notifier the option of returning something beyond what is specified, such as a set of location URIs when only a civic location was requested.

「正確な」属性のための「偽」のデフォルト値は、通知にのみ市民の場所が要求されたときにそのような場所のURIのセットとして指定されているものを超えた何かを、返却のオプションを可能にします。

An example is shown in Figure 8 that utilizes the <locationType> element with the 'exact' attribute.

例は、「正確な」属性と<locationType>要素を利用し、図8に示されています。

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter" xmlns:lf="urn:ietf:params:xml:ns:location-filter"> <filter id="123" uri="sip:presentity@example.com"> <what> <lf:locationType exact="true"> geodetic </lf:locationType> </what> </filter> </filter-set>

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター" のxmlns：LF = "壷：IETF：のparams：XML ：NS：位置フィルタ "> <フィルタID =" 123" URI = "SIP：presentity@example.com"> <何> <LF：locationType正確= "" 真>測地</ LF：locationType> </何> </フィルタ> </フィルタセット>

Figure 8: <locationType> Filter Example

図8：<locationType>フィルタの例

3.6. Rate Control

3.6. レート制御

[RFC6446] extends the SIP events framework by defining three Event header field parameters that allow a subscriber to set a minimum, a maximum, and an adaptive minimum of event notifications generated by the notifier. This allows a subscriber to have overall control over the stream of notifications, for example to avoid being flooded. Two of the parameters, namely "min-rate" (which specifies a minimum notification rate per second) and "max-rate" (which specifies a maximum notification rate per second) are used by this document. Only the implementation of these two attributes is required from the attributes defined in [RFC6446]. Whenever the time since the most recent notification exceeds the interval corresponding to 1 / "min-rate", the current state would be sent in its entirety, just like after a subscription refresh.

[RFC6446]は、加入者が最小、最大、および通知によって生成されたイベント通知の適応最小値を設定することを可能にする3つのイベントヘッダフィールドパラメータを定義することによりSIPイベント・フレームワークを拡張します。これは、加入者が例えば浸水されるのを避けるために、通知の流れの上に全体的な制御を持つことができます。（毎秒最大通知レートを指定）（毎秒最小通知レートを指定する）のパラメータ、すなわち「分率」と「最大レート」の2つは、この文書で使用されています。これら二つの属性の唯一の実装は、[RFC6446]で定義された属性から要求されます。最新の通知からの時間は、1 /「分率」に対応する間隔を超えるたびに、現在の状態がちょうどサブスクリプションの更新の後のように、その全体が送信されます。

A notifier is required to send a NOTIFY request immediately after creation of a subscription. If state is not available at that time, then the NOTIFY request may be sent with no content. A separate NOTIFY containing location is subsequently generated so that the rate of notification since the last NOTIFY falls between "min-rate" and "max-rate". An important use case for location-based applications focuses on the behavior of the initial NOTIFY message(s) and the information it returns, for example in case of emergency call routing. When an initial NOTIFY is transmitted, it might not include complete state.

通知は、サブスクリプションの作成後すぐにNOTIFYリクエストを送信するために必要とされます。状態は、その時点で利用できない場合、要求は無いコンテンツと一緒に送信することができるNOTIFY。最後以来の通知の速度は「最小速度」と「最大レート」の間に入るをNOTIFYように別個のNOTIFYを含む位置は、その後に生成されます。位置ベースのアプリケーションのための重要なユースケースは、初期NOTIFYメッセージ（単数または複数）と緊急コールルーティングの場合、例えば、それが返した情報の挙動に焦点を当てています。初期は、NOTIFYが送信されると、それは完全な状態が含まれない場合があります。

      Subscriber          Notifier
          |---SUBSCRIBE(1)--->|  Create subscription (w/large value
          |<-------200--------|    for min-rate and max-rate)
          |<-----NOTIFY(2)----|  Return initial notify with no state
          |--------200------->|
          |        ...        |
          |<-----NOTIFY(3)----|  Return full state (between min-rate
          |--------200------->|    and max-rate)
          |---SUBSCRIBE(4)--->|  Update subscription (to update
          |<-------200--------|    min-rate and max-rate)

Figure 9: SUBSCRIBE/NOTIFY with Rate Control

図9：レート制御とSUBSCRIBE / NOTIFY

Figure 9 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE message (1) has filters attached and contains a "min-rate" rate control parameter. In certain situations, it is important to obtain some amount of location information within a relatively short and pre-defined period of time, even if the obtained location information contains a high amount of uncertainty and location information with less uncertainty could be available at a later point in time. An example is emergency call routing where an emergency services routing proxy may need to obtain location information suitable for routing rather quickly and subsequently a Public Safety Answering Point requests location information for dispatch.

図9は、SUBSCRIBE / NOTIFY交換を示しています。最初のメッセージは、（1）添付のフィルタを有し、「最小速度」レート制御パラメータが含まSUBSCRIBE。特定の状況では、取得した位置情報が後に利用可能とすることができるより少ない不確実性と不確実性と位置情報の高い量を含んでいても、時間の比較的短いと予め定義された期間内の位置情報のいくつかの量を得ることが重要です時点。一例では、緊急サービスルーティングプロキシはポイントがディスパッチのための位置情報を要求応答素早く、その後、むしろ公安をルーティングするのに適した位置情報を取得する必要があり、緊急コールルーティングです。

To obtain location information in a timely fashion using the SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial SUBSCRIBE contain a "min-rate" rate control parameter (with a large value, corresponding to a very short delay before the next notification) that is updated in a later message to a more sensible value. This provides equivalent functionality to the 'responseTime' attribute in Section 6.1 of [RFC5985]. The "min-rate" for this first request is therefore much larger (much more rapid) than the updated "min-rate" value. Depending on the value in the "min-rate" parameter, the Notifier may immediately send the initial NOTIFY message (see message 2) without a body if no location information is available at this point in time. The desired location information may then arrive in the subsequent NOTIFY message (see message 3). Updating the "min-rate" for the subscription can be performed in the 200 response (see message 3) to the NOTIFY that contains location state, or in a subsequent SUBSCRIBE request (as in message 4).

SUBSCRIBE / NOTIFY機構を利用してタイムリーに位置情報を得るためには、最初の（次の通知前に、非常に短い遅延時間に対応する、大きな値を有する）「最小速度」レート制御パラメータを含むSUBSCRIBEことが推奨されもっと賢明な値に後でメッセージで更新されます。これは、[RFC5985]の6.1節の「RESPONSETIME」属性に同等の機能を提供します。この最初の要求のために、「最小速度」は、従って更新「分率」の値よりも（はるかに迅速な）非常に大きいです。いかなる位置情報はこの時点で使用できない場合、「最小速度」パラメータの値に応じて、通知はすぐ体なし初期NOTIFYメッセージ（メッセージ2を参照）を送信することができます。所望の位置情報は、その後、（メッセージ3を参照）、その後のNOTIFYメッセージで到着してもよいです。サブスクリプションの「MIN-率」を更新することは、位置状態が含まれている、または（メッセージ4のように）後続のSUBSCRIBEリクエストに通知する（メッセージ3を参照）200応答して行うことができます。

4. XML Schema

4. XMLスキーマ

<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:location-filter" xmlns:filter="urn:ietf:params:xml:ns:location-filter" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml">

<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "URN：IETF：paramsは：XML：NS：位置フィルタ" のxmlns：フィルタ= "URN：IETF：paramsはを：XML ：NS：位置フィルタ」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のxmlns：GML = "http://www.opengis.net/gml">

<xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>

<XS：要素名= "enterOrExit" タイプ= "GML：GeometryPropertyType" />

<xs:element name="moved" type="filter:movedType"/>

<XS：要素名は=タイプ= "移動" "フィルタ：movedTypeを" />

<xs:complexType name="movedType"> <xs:simpleContent> <xs:extension base="xs:double"> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType>

<XS：complexTypeの名= "movedType"> <XS：simpleContentを> <XS：増設ベース= "XS：ダブル"> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの>

<xs:element name="locationType" type="filter:locationTypeType"/>

<XS：要素名= "locationType" タイプ= "フィルタ：locationTypeType" />

<xs:simpleType name="locationTypeBase"> <xs:union> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="any"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="filter:locationTypeList"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType>

<XS：単純型名= "locationTypeBase"> <XS：組合> <XS：単純> <XS：制限ベース= "XS：トークン"> <XS：列挙値= "任意" /> </ XS：制限> < / XS：単純> <XS：単純> <XS：制限ベース= "フィルタ：locationTypeList"> <XS：はminLength値= "1" /> </ XS：制限> </ XS：単純> </ XS：組合> </ XS：単純>

<xs:simpleType name="locationTypeList"> <xs:list> <xs:simpleType> <xs:restriction base="xs:token"> <xs:enumeration value="civic"/> <xs:enumeration value="geodetic"/> </xs:restriction> </xs:simpleType> </xs:list> </xs:simpleType>

<XS：単純型名= "locationTypeList"> <XS：リスト> <XS：単純> <XS：制限ベース= "XS：トークン"> <XS：列挙値= "市民" /> <XS：列挙値=」測地 "/> </ XS：制限> </ XS：単純> </ XS：リスト> </ XS：単純>

<xs:complexType name="locationTypeType"> <xs:simpleContent> <xs:extension base="filter:locationTypeBase"> <xs:attribute name="exact" type="xs:boolean" use="optional" default="false"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:schema>

<XS：complexTypeの名前= "locationTypeType"> <XS：simpleContentを> <XS：増設ベース= "フィルタ：locationTypeBase"> <XS：属性名= "正確な" タイプ= "XS：ブール" 使用= "オプションの" デフォルト= "偽" /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：スキーマ>

Figure 10: XML Schema

図10：XMLスキーマ

5. Security Considerations

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

This document specifies one element, namely filters, utilized in larger systems. As such, this document builds on a number of specifications for the security of the complete solution, namely

この文書では、大規模なシステムで利用される1つの要素、すなわちフィルタを指定します。そのため、この文書では、すなわち、完全なソリューションのセキュリティのための仕様の数に基づいています

o the SIP event notification mechanism, described in RFC 3265 [RFC3265], defining the SUBSCRIBE/NOTIFY messages.

SUBSCRIBE / NOTIFYメッセージを規定するRFC 3265に記載のSIPイベント通知機構、[RFC3265]は、O。

o the presence event package, described in RFC 3856 [RFC3856], which is a concrete instantiation of the general event notification framework.

一般的なイベント通知フレームワークの具体化であるRFC 3856に記載のプレゼンス・イベント・パッケージ、[RFC3856]、O。

o the filter framework, described in RFC 4661 [RFC4661], to offer the ability to reduce the amount of notifications being sent.

フィルタフレームワークO、送信される通知の量を減少させる能力を提供するために、RFC 4661に[RFC4661]を説明しました。

Finally, this document indirectly (via the SIP presence event package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the XML container that carries location information.

最後に、（SIPプレゼンス・イベント・パッケージを介して）間接的にこの文書は、位置情報を運ぶXML容器として、RFC 4119に記載PIDF-LO、[RFC4119]に依存しています。

Each of the documents listed above comes with a Security Considerations section but the security and privacy aspects are best covered by the SIP presence event package; see Section 9 of [RFC3856], and with the GEOPRIV architectural description found in [RFC6280].

上記各文献のは、Security Considerations部が付属していますが、セキュリティとプライバシーの面は、最良のSIPプレゼンスイベントパッケージによって覆われています。、および[RFC6280]に見出さGEOPRIVアーキテクチャの記述と[RFC3856]のセクション9を参照してください。

The functionality offered by authorization policies to limit access to location information is provided by other protocols, such as Common Policy [RFC4745], Geolocation Policy [GEO-POLICY], or more recent work around HTTP-Enabled Location Delivery (HELD) context [HELD]. Although [GEO-POLICY] defines a standardized format for geolocation authorization policies, it does not define specific policies for controlling filters.

位置情報へのアクセスを制限するために、認可ポリシーによって提供される機能は、このような共通のポリシー[RFC4745]、ジオロケーションポリシー[GEO-POLICY]、またはHTTP対応の場所の配達（保持）文脈の周りに、より最近の作品など、他のプロトコルによって提供される[HELD ]。 [GEO-POLICY]はジオロケーション承認ポリシーのための標準化された形式を定義しますが、それは、フィルタを制御するための特定のポリシーを定義していません。

The functionality described in this document extends the filter framework with location-specific filters. Local policies might be associated with the usage of certain filter constructs and with the amount of notifications that specific filter settings might cause. Uploading filters have a significant effect on the ways in which the request is handled at a server. As a result, it is especially important that messages containing this extension be authenticated and authorized. RFC 4661 [RFC4661] discusses this security threat and proposes authentication and authorization solutions applicable to this specification.

本書で説明した機能は、位置特定のフィルタを有するフィルタフレームワークを拡張します。ローカルポリシーは、特定のフィルタ構築物の使用方法で、特定のフィルタ設定が原因かもしれない通知の量に関連付けられている可能性があります。アップロードフィルタは、要求がサーバーで処理されている方法に大きな影響を持っています。その結果、この拡張機能を含むメッセージを認証および承認することが特に重要です。 RFC 4661 [RFC4661]は、このセキュリティ上の脅威について説明し、この仕様に適用される認証と認可のソリューションを提案しています。

6. IANA Considerations

6. IANAの考慮事項

6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-filter

6.1. 骨壷用URNサブ名前空間の登録：IETF：paramsは：XML：NS：位置フィルタ

This section registers a new XML namespace, as per the guidelines in [RFC3688].

このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。

URI: urn:ietf:params:xml:ns:location-filter

URI：URN：IETF：paramsは：XML：NS：位置フィルタ

Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>, as delegated by the IESG <iesg@ietf.org>.

登録者連絡先：IETF、GEOPRIVワーキンググループ、<geopriv@ietf.org>、IESG <iesg@ietf.org>から委任として。

XML:

XML：

BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Location Filter Namespace</title> </head> <body> <h1>Namespace for PIDF-LO Location Filters</h1> <h2>urn:ietf:params:xml:ns:location-filter</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc6447.txt"> RFC 6447</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 =イソPIDF-LOロケーションフィルタの8859-1" /> <タイトル>ロケーションフィルタ名前空間</タイトル> </ head> <body> <H1>名前空間</ H1> <H2> URN：IETF：paramsは：XML：NS：位置フィルタ</ H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc6447.txt"> RFC 6447 </a>をご覧ください。</ P> </ BODY> </ HTML> END

6.2. Schema Registration for location-filter

6.2. 場所・フィルタのスキーマの登録

This specification registers a schema, as per the guidelines in [RFC3688].

この仕様は、[RFC3688]のガイドラインに従って、スキーマを登録します。

URI: urn:ietf:params:xml:schema:location-filter

URI：URN：IETF：paramsは：XML：スキーマ：位置フィルタ

Registrant Contact: IETF, GEOPRIV Working Group (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org).

登録者連絡先：IETF、GEOPRIVワーキンググループ（geopriv@ietf.org）、IESGから委任として（iesg@ietf.org）。

XML: The XML can be found as the sole content of Section 4.

XML：XMLは、第4節の唯一の内容として求めることができます。

7. Contributors

7.寄与

We would like to thank Martin Thomson and James Polk for their contributions to this document.

私たちは、この文書への貢献のためにマーティン・トムソンとジェームズ・ポークに感謝したいと思います。

8. Acknowledgments

8.謝辞

Thanks to Richard Barnes, Alissa Cooper, Randall Gellens, Carl Reed, Ben Campbell, Adam Roach, Allan Thomson, and James Winterbottom for their comments.

彼らのコメントのためのリチャード・バーンズ、アリッサ・クーパー、ランドールGellens、カール・リード、ベン・キャンベル、アダムローチ、アラン・トムソン、そしてジェームズ・ウィンターボトムに感謝します。

Furthermore, we would like to thank Alexey Melnikov for his IESG review comments.

さらに、我々は彼のIESGレビューコメントをアレクセイ・メルニコフに感謝したいと思います。

9. References

9.参考文献

9.1. Normative References

9.1. 引用規格

[GML] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OpenGIS OGC 02-023r4, January 2003, <http://www.opengis.org/techno/implementation.htm>.

[GML] OpenGISの、 "オープン地理マークアップ言語（GML）実装仕様"、OpenGISのOGC 02-023r4、2003年1月、<http://www.opengis.org/techno/implementation.htm>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.

[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。

[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.

[RFC3856]ローゼンバーグ、J.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、2004年8月。

[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.

[RFC4119]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。

[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "An Extensible Markup Language (XML)- Based Format for Event Notification Filtering", RFC 4661, September 2006.

[RFC4661] Khartabil、H.、Leppanen、E.、Lonnfors、M.、およびJ.コスタ・レケーナ、 "拡張マークアップ言語（XML） - イベント通知のフィルタリングのためのベースのフォーマット"、RFC 4661、2006年9月。

[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.

[RFC5491]ウィンターボトム、J.、トムソン、M.、およびH. Tschofenig、 "GEOPRIVプレゼンス情報データフォーマット場所オブジェクト（PIDF-LO）使用法の明確化、考慮事項、および推奨事項"、RFC 5491、2009年3月。

[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", RFC 5962, September 2010.

[RFC5962] Schulzrinneと、H.、シン、V.、Tschofenig、H.、およびM.トムソン、RFC 5962、2010年9月、 "プレゼンス情報データフォーマット場所オブジェクト（PIDF-LO）への動的拡張機能"。

[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.

[RFC6280]バーンズ、R.、Lepinski、M.、クーパー、A.、モリス、J.、Tschofenig、H.、およびH. Schulzrinneと、 "インターネットアプリケーションにおける場所と場所のプライバシーのためのアーキテクチャ"、BCP 160、RFC 6280、2011年7月。

[RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control", RFC 6446, January 2012.

[RFC6446]ニエミ、A.、キス、K.、およびS.ロレート、 "通知レート制御のためのセッション開始プロトコル（SIP）イベント通知拡張"、RFC 6446、2012年1月。

9.2. Informative References

9.2. 参考文献

[GEO-POLICY] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, October 2011.

[GEO-POLICY] Schulzrinneと、H.、Tschofenig、H.、クエリャル、J.、ポーク、J.、モリス、J.、およびM.トムソン、 "ジオロケーションポリシー：位置情報のためのプライバシー設定を表現するためのドキュメントフォーマット" 、進歩、2011年10月に作業。

[HELD] Winterbottom, J., Tschofenig, H., and M. Thomson, "Location URI Contexts in HTTP-Enabled Location Delivery (HELD)", Work in Progress, October 2009.

ウィンターボトム、J.、Tschofenig、H.、およびM.トムソン、 "（保持）HTTP対応の場所配信中の場所URIコンテキスト"、進歩、2009年10月に作業を[HELD]。

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.

[RFC4745] Schulzrinneと、H.、Tschofenig、H.、モリス、J.、クエリャル、J.、ポーク、J.、およびJ.ローゼンバーグ、 "共通ポリシー：プライバシー設定を表現するためのドキュメントフォーマット"、RFC 4745、2月2007。

[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.

[RFC5985]バーンズ、M.、 "HTTP対応の場所デリバリー（保持）"、RFC 5985、2010年9月。

[SIP-LOC] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", Work in Progress, September 2011.

[SIP-LOC]ポーク、J.、ローゼン、B.、およびJ.ピーターソン、 "セッション開始プロトコルのための場所の搬送"、進歩、2011年9月ワーク。

Authors' Addresses

著者のアドレス

Rohan Mahy Individual

ロハンマーイ個々

EMail: rohan@ekabal.com

メールアドレス：rohan@ekabal.com

Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 US

ブライアン・ローゼンNeuStar 470コンラッド博士は火星、PA 16046米国

Phone: +1 724 382 1051 EMail: br@brianrosen.net

電話：+1 724 382 1051 Eメール：br@brianrosen.net

Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland

ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド

Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at

電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at