[要約] RFC 6447は、SIPにおける位置通知のフィルタリングに関する規格です。このRFCの目的は、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)
セッション開始プロトコル（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).
このドキュメントでは、非同期の場所通知を説得力のあるイベントに制限するフィルターについて説明します。これらのフィルターは、イベント通知フィルタリング用のXMLベースの形式であるRFC 4661の拡張機能として設計されており、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6447で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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.
存在情報データ形式でカプセル化された位置情報を伝える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. ターゲットは、円またはポリゴンで記述された2次元領域に入るか終了します（セクション3.4を参照）。
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.
5. 要求された位置情報のタイプ（セクション3.5を参照）、たとえば、市民から測地位置に変更するか、その逆に変更されます。
6. a certain amount of time passes (see Section 3.6).
6. 一定の時間が経過します（セクション3.6を参照）。
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]から用語を再利用します。
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-bindings>要素（[rfc4661]のセクション3.3を参照）;<filter>要素（[RFC4661]のセクション3.4）;および<trigger>要素（[rfc4661]のセクション3.6）、<added>および<removed>サブ要素を除きます。
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.
<moved>要素には、このイベントをトリガーするために最後の通知が送信されたため、リソースがリソースの場所から移動した必要がある最小距離を示すメーターの値をメーターに含める必要があります。距離は、最後の通知のポイントから絶対にメーターで測定する必要があり、垂直運動を含める必要があります。<moved>要素は、<filter>要素の子要素として複数回表示してはなりません。
<?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>
Figure 1: Movement Filter Example
図1：移動フィルターの例
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]で定義されている空間方向、速度、見出し、および加速度のためのRFC 4661の機能をPIDF-LO拡張機能と組み合わせることにより、速度の変化をフィルタリングできます。[rfc5962]の<speed>要素の値は、1秒あたりのメートルで定義する必要があります。条件は、高度を含むあらゆる軸の変化によって満たされる可能性があることに注意してください。
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>
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-bindings>をサポートする必要があります。XPath式は、「//」に続いて単一の要素で開始する必要があります。XPath発現の他の形式はサポートされていません。<chander>要素にはいくつかの属性が付属していますが、この仕様では「by」属性のみを実装する必要があります。
Changes in values, for example related to civic location information, is provided by the base functionality offered with RFC 4661 utilizing the <changed> element.
たとえば、市民の位置情報に関連する値の変更は、<Changed>要素を利用して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" 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 from="FR">//ca:country</changed>
</trigger>
</filter>
</filter-set>
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のリストのいずれかの要素が変更されるかどうかを知ることが望ましい場合は、要素値のいずれかが変更されたときにサブスクライバーに通知されるように、個別の<changes>フィルターに配置する必要があります。図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>
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の変更（両方の要素が変更されるためには両方の要素が変更されなければならない場合に通知が送信される例を示しています。
(Only a change in BOTH tokens triggers an event.)
（両方のトークンの変更のみがイベントをトリガーします。）
<?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:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
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-bindings>をサポートする必要があります。XPath式は、「//」に続いて単一の要素で開始する必要があります。XPath発現の他の形式はサポートされていません。他のバリアントはサポートされていません。<Changed>要素には、いくつかの属性と「by」、「to」、および「from」属性がこの仕様をサポートするために実装する必要があります。
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で定義されているように）または円（[RFC5491]のセクション5.2.3で定義されているように）によって記述された2次元領域に入るまたは終了すると満たされます。）。<Enterorexit>要素には、子要素としてポリゴンまたは円のいずれかを含める必要があります。<Enterorexit>要素には、1つ以上のポリゴンおよび/または円を備えている必要があります。
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
ターゲットがエリア内にあるという50％の信頼性を持つことは、外の50％に対応していないことに注意してください。場所が地域内にあるという自信に加えて、場所があるという自信
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.
地域の外側は、場所の信頼に限定されています。完全な信頼は、場所の信頼に依存します。これは常に100％未満です（[RFC5491]では95％が推奨されます）。これの利点は、通知が自然に制限されていることです。地域の境界での小さな動き（場所の不確実性と比較して）は通知をトリガーしないことです。
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">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gs:Circle
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius
uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
Figure 6: <enterOrExit> Circle Filter Example
<?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">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
<gml:pos>43.111 -73.322</gml:pos>
<!--F-->
<gml:pos>43.111 -73.222</gml:pos>
<!--E-->
<gml:pos>43.311 -73.122</gml:pos>
<!--D-->
<gml:pos>43.411 -73.222</gml:pos>
<!--C-->
<gml:pos>43.411 -73.322</gml:pos>
<!--B-->
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
Figure 7: <enterOrExit> Polygon Filter Example
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>要素は、<what>要素の子要素として含めることができます。これには、サブスクライバーが要求する位置情報タイプのリストが含まれています。次のリストでは、可能な値について説明します。
any: The Notifier SHOULD attempt to provide location information in all forms available to it.
いずれか：通知者は、利用可能なあらゆる形式の位置情報を提供しようとする必要があります。
geodetic: The Notifier SHOULD return a location by value in the form of a geodetic location.
測地：通知者は、測地位置の形式で値で場所を返す必要があります。
civic: The Notifier SHOULD return a location by value in the form of a civic address.
CIVIC：通知者は、市民住所の形で価値によって場所を返す必要があります。
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 Returnsが返す場所のタイプは、オプションの「Exact」属性の設定にも依存します。「正確な」属性が「true」に設定されている場合、Notifierは要求されたロケーションタイプまたはロケーション情報なしのいずれかを返す必要があります。「any」の場所タイプのリクエストには、「正確」属性は適用されません（無視されます）。
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）と「正確な」属性の要求が「false」である場合、Notifierは追加のロケーションタイプを提供するか、要求されたロケーションタイプの要求が満たされない場合、代替タイプを提供する場合があります。
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:
通知者は、両方が明示的に要求された場合、リクエストの「LocationType」要素に含まれていたのと同じ順序で、応答に市民および測地の位置情報を提供する必要があります。実際、「正確な」属性が「false」に設定されている場合、特定のロケーションタイプをリクエストに含めることの主な利点は、特定の順序で利用可能な場所を受信することを確認することです。たとえば、「civic」のサブスクリプション（「false」に設定された「正確な」属性を使用）は、応答内の次のロケーションタイプのいずれかを生成する可能性があります。
o civic
o シビック
o civic, geodetic
o 市民、測地
o geodetic (only if civic is not available)
o 測地（Civicが利用できない場合のみ）
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.
「正確な」属性の「false」のデフォルト値は、市民の場所のみが要求された場合の場所のセットなど、指定されているものを超えて何かを返すオプションを通知者に許可することができます。
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>
Figure 8: <locationType> Filter Example
[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つのパラメーター、つまり「MIN-Rate」（最小通知レートあたりの最小通知率を指定）と「最大通知率を指定する」（最大通知率を指定）とする2つのパラメーターが使用されます。[RFC6446]で定義されている属性から、これら2つの属性の実装のみが必要です。最新の通知が1 /「MIN-RATE」に対応する間隔を超える時間があるときはいつでも、サブスクリプションの更新後のように、現在の状態が完全に送信されます。
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.
宛先は、サブスクリプションを作成した直後に通知リクエストを送信する必要があります。その時点で状態が利用できない場合、コンテンツなしで通知要求が送信される場合があります。その後、個別の通知を含む場所が生成され、最後の通知が「最小レート」と「MAX-RATE」の間に通知された通知率が生成されます。ロケーションベースのアプリケーションの重要なユースケースは、緊急通話ルーティングの場合、初期通知メッセージの動作と返品する情報に焦点を当てています。最初の通知が送信されると、完全な状態が含まれない場合があります。
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：レートコントロールを備えた購読/通知
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は、購読/通知交換を示しています。初期サブスクライブメッセージ（1）にはフィルターが添付されており、「最小レート」レート制御パラメーターが含まれています。特定の状況では、取得した位置情報が高額の不確実性を含んでいても、不確実性が少ない場合に利用できる可能性がある場合でも、比較的短期および事前定義された期間内にある程度の位置情報を取得することが重要です。時間内。例としては、緊急通話ルーティングがあり、緊急サービスルーティングプロキシがルーティングに適した位置情報を取得する必要がある場合があります。
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).
サブスクライブ/通知メカニズムを使用してタイムリーに位置情報を取得するには、初期サブスクライブには「最小レート」レート制御パラメーター（次の通知の前に非常に短い遅延に対応する大きな値を持つ）を含めることをお勧めします。後のメッセージでより賢明な価値に更新されます。これにより、[RFC5985]のセクション6.1の「応答」属性と同等の機能が提供されます。したがって、この最初のリクエストの「最小レート」は、更新された「最小レート」値よりもはるかに大きい（はるかに速い）。 「最小レート」パラメーターの値に応じて、通知者は、この時点でロケーション情報が利用できない場合は、本文なしで最初の通知メッセージ（メッセージ2を参照）をすぐに送信できます。目的の位置情報は、後続の通知メッセージに到着する場合があります（メッセージ3を参照）。サブスクリプションの「最小レート」を更新することは、200の応答（メッセージ3を参照）で、ロケーション状態を含む通知、またはその後のサブスクライブリクエスト（メッセージ4のように）で実行できます。
<?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">
<xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>
<xs:element name="moved" type="filter: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:element name="locationType" type="filter: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: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: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>
Figure 10: XML Schema
図10：XMLスキーマ
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.
o RFC 3265 [RFC3265]で説明されているSIPイベント通知メカニズムは、サブスクライブ/通知メッセージを定義します。
o the presence event package, described in RFC 3856 [RFC3856], which is a concrete instantiation of the general event notification framework.
o RFC 3856 [RFC3856]に記載されているプレゼンスイベントパッケージは、一般的なイベント通知フレームワークの具体的なインスタンス化です。
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プレゼンスイベントパッケージを介して）、RFC 4119 [RFC4119]に記載されているPIDF-LOに依存しています。
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].
上記の各ドキュメントにはセキュリティに関する考慮事項セクションが付属していますが、セキュリティとプライバシーの側面は、SIPプレゼンスイベントパッケージで最もよくカバーされています。[RFC3856]のセクション9を参照し、[RFC6280]にあるGeoprivの建築記述を参照してください。
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]、Geolocation Policy [Geo-Policy]、またはHTTP対応のロケーション配信（開催）コンテキストに関する最近の研究[Geo-Policy]など、他のプロトコルによって提供されます。]。[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.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter
This section registers a new XML namespace, as per the guidelines in [RFC3688].
このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:location-filter
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
This specification registers a schema, as per the guidelines in [RFC3688].
この仕様は、[RFC3688]のガイドラインに従って、スキーマを登録します。
URI: urn:ietf:params:xml:schema:location-filter
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の唯一の内容として見つけることができます。
We would like to thank Martin Thomson and James Polk for their contributions to this document.
この文書への貢献について、マーティン・トムソンとジェームズ・ポークに感謝します。
Thanks to Richard Barnes, Alissa Cooper, Randall Gellens, Carl Reed, Ben Campbell, Adam Roach, Allan Thomson, and James Winterbottom for their comments.
リチャード・バーンズ、アリッサ・クーパー、ランドール・ゲレンズ、カール・リード、ベン・キャンベル、アダム・ローチ、アラン・トムソン、ジェームズ・ウィンターボトムのコメントに感謝します。
Furthermore, we would like to thank Alexey Melnikov for his IESG review comments.
さらに、IESGレビューのコメントについてAlexey Melnikovに感謝します。
[GML] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OpenGIS OGC 02-023r4, January 2003, <http://www.opengis.org/techno/implementation.htm>.
[GML] OpenGis、「Open Geography Markup Language（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、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.、Lonfors、M。、およびJ. Costa-Requena、「イベント通知フィルタリング用の拡張可能なマークアップ言語（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] Winterbottom、J.、Thomson、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.、Singh、V.、Tschofenig、H.、およびM. Thomson、「存在情報データ形式のダイナミック拡張機能（PIDF-LO）」、RFC 5962、2010年9月。
[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] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「インターネットアプリケーションの場所と場所のプライバシーのアーキテクチャ」、BCP 160、RFC6280、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] Niemi、A.、Kiss、K。、およびS. Loreto、「セッション開始プロトコル（SIP）通知レート制御のためのイベント通知拡張」、RFC 6446、2012年1月。
[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.、Cuellar、J.、Polk、J.、Morris、J。、およびM. Thomson、「地理配置ポリシー：位置情報のプライバシー設定を表現するためのドキュメント形式」、2011年10月に進行中の作業。
[HELD] Winterbottom, J., Tschofenig, H., and M. Thomson, "Location URI Contexts in HTTP-Enabled Location Delivery (HELD)", Work in Progress, October 2009.
[保有] Winterbottom、J.、Tschofenig、H。、およびM. Thomson、「HTTP対応の位置配信の場所URIコンテキスト（開催）」、2009年10月、進行中の作業。
[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.、Morris、J.、Cuellar、J.、Polk、J。、およびJ. Rosenberg、「共通政策：プライバシーの好みを表現するためのドキュメント形式」、RFC 4745、2月2007年。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、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] POLK、J.、ROSEN、B。、およびJ. Peterson、「セッション開始プロトコルの位置輸送」、2011年9月、進行中の作業。
Authors' Addresses
著者のアドレス
Rohan Mahy Individual
Rohan Mahy個人
EMail: rohan@ekabal.com
Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 US
ブライアン・ローゼン・ノイスター470コンラッド・ドクター・マーズ、ペンシルベニア州16046米国
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at