RFC 4660 - Functional Description of Event Notification Filtering 日本語訳

URL : https://tools.ietf.org/html/rfc4660
タイトル : RFC 4660 - イベント通知フィルタリングの機能説明
翻訳編集 : 自動生成

Network Working Group                                       H. Khartabil
Request for Comments: 4660                                         Telio
Category: Standards Track                                    E. Leppanen
                                                             M. Lonnfors
                                                        J. Costa-Requena
                                                                   Nokia
                                                          September 2006

         Functional Description of Event Notification Filtering

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2006）。

Abstract

抽象

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.

SIPイベント通知フレームワークは、サブスクリプションおよびリソースの状態への変更の通知のためのセッション開始プロトコル（SIP）の使用を記載しています。文書は、イベント通知情報のフィルタリングを達成することができる機構を記載していません。

This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed.

この文書では、代わりにイベント通知情報へのサブスクリプションに関連付けられているフィルタリングルールを置くために、加入者が実行する操作について説明します。、加入者によって、応答のフィルタリングルールおよびそれらに適用されるフィルタリングルールと通知の処理を担持するサブスクリプションの取り扱いも記載されています。また、ドキュメントは、そのようなフィルタリングルールを受信し、通知がどのように構成されているときに通知がどのように動作するかを伝えます。

Table of Contents

   1. Introduction ....................................................3
   2. Conventions .....................................................3
   3. Client Operation ................................................4
      3.1. Transport Mechanism ........................................4
      3.2. SUBSCRIBE Bodies ...........................................4
      3.3. Subscriber Generating of SUBSCRIBE Requests ................4
           3.3.1. Defining the Filtering Rules ........................4
           3.3.2. Request-URI vs. Filter URI ..........................5
           3.3.3. Changing Filters within a Dialog ....................5
           3.3.4. Subscriber Interpreting of SIP Responses ............6
      3.4. Subscriber Processing of NOTIFY Requests ...................6
   4. Resource List Server Behaviour ..................................7
      4.1. Request-URI vs. Filter URI .................................7
      4.2. Changing Filters within a Dialog ...........................9
   5. Server Operation ................................................9
      5.1. NOTIFY Bodies ..............................................9
      5.2. Notifier Processing of SUBSCRIBE Requests ..................9
           5.2.1. Request-URI vs. Filter URI .........................10
           5.2.2. Changing Filters within a Dialog ...................11
      5.3. Notifier Generating of NOTIFY Requests ....................11
           5.3.1. Generation of NOTIFY Contents ......................12
           5.3.2. Handling of Notification Triggering Rules ..........13
      5.4. Handling Abnormal Cases ...................................13
   6. XML Document Validation ........................................14
   7. Examples .......................................................14
      7.1. Presence Specific Examples ................................14
           7.1.1. Subscriber Requests Messaging-Related Information ..15
           7.1.2. Subscriber Fetches Information about "Open"
                  Communication Means ................................16
           7.1.3. Subscriber Requests Notifications When
                  Presentity's Status Changes ........................18
      7.2. Watcher Information Specific Examples .....................21
           7.2.1. Watcher Subscriber Makes Subscription to
                  Get All the Information about Active Watchers ......22
           7.2.2. Watcher Subscriber Requests Information of
                  Watchers with Specific Subscription Duration
                  Conditions .........................................23
           7.2.3. Watcher Subscriber Requests Specific
                  Watcher Info on Specific Triggers ..................24
   8. Security Considerations ........................................27
   9. IANA Considerations ............................................28
   10. Acknowledgements ..............................................28
   11. References ....................................................28
      11.1. Normative References .....................................28
      11.2. Informative References ...................................28

1. Introduction

1. はじめに

SIP event notification is described in [3]. It defines a general framework for sending subscriptions and receiving notifications in SIP-based systems. It introduces the concept of event packages, which are concrete applications of the general event framework to a specific usage of events.

SIPイベント通知は、[3]に記載されています。これは、サブスクリプションを送信し、SIPベースのシステムで通知を受信するための一般的なフレームワークを定義します。これは、イベントの具体的な使用への一般的なイベントフレームワークの具体的なアプリケーションでイベントパッケージの概念を導入しています。

Filtering is a mechanism for controlling the content of event notifications. Additionally, the subscriber may specify the rules for when a notification should be sent to it. The filtering mechanism is expected to be particularly valuable to users of mobile wireless access devices. The characteristics of the devices typically include high latency, low bandwidth, low data processing capabilities, small display, and limited battery power. Such devices can benefit from the ability to filter the amount of information generated at the source of the event notification. However, implementers need to be aware of the computational burden on the source of the event notification. This is discussed further in Section 8.

フィルタリングは、イベント通知の内容を制御する機構です。また、加入者は、通知がそれに送信されなければならないときのための規則を指定することができます。フィルタリング機構は、モバイル無線アクセスデバイスのユーザに特に有用であると予想されます。デバイスの特性は、典型的には、高遅延、低帯域幅、低データ処理能力、小さなディスプレイ、および限られたバッテリ電力を含みます。そのようなデバイスは、イベント通知の送信元で生成される情報の量をフィルタする能力から利益を得ることができます。しかし、実装者は、イベント通知のソース上の計算負荷を認識する必要があります。これは、8章で詳しく説明されています。

It is stated in [3] that the notifier may send a NOTIFY at any time, but typically it is sent when the state of the resource changes. It also states that the notifications would contain the complete and current state of the resource authorized for a certain subscriber to see. The format of such resource state information is package specific. In this memo, we assume that the NOTIFY for any package contains an XML document.

通知がいつでもNOTIFYを送信することができるが、典型的には、ときに、リソースの状態が変化送信される[3]に記載されています。また、通知は、特定の加入者が見ることを許可リソースの完全かつ現在の状態が含まれているだろうと述べています。そのようなリソースの状態情報のフォーマットは、特定のパッケージです。このメモでは、我々はすべてのパッケージのNOTIFYは、XML文書が含まれていることを前提としています。

This document, together with [5], presents a mechanism for filtering whereby a subscriber describes its preference of when notifications are to be sent to it and what they are to contain. It also describes how the notifier functions when generating notifications by taking into account filters and default functionality of the package/ service.

この文書では、[5]、フィルタリングのための機構を提示すると共に、加入者は、その通知がそれに送信する場合の嗜好と彼らが含むようにしているを説明します。また、アカウントのフィルターやパッケージ/サービスのデフォルトの機能を考慮することにより、通知を生成するときにどのように通知機能について説明します。

The XML format for defining the filter is described in [5].

フィルタを定義するためのXMLフォーマットは、[5]に記載されています。

2. Conventions

2.表記

In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.

この文書では、キーワード 'MUST'、 'MUST NOT'、 'REQUIRED'、 'SHALL'、 'NOT SHALL'、 'SHOULD'、 'すべきではありません'、 '推奨'、 'MAY'、および 'OPTIONAL' RFC 2119に記載されるように解釈されるべきである[1]と対応する実装の要求レベルを示します。

"Content" refers to the XML document that appears in a notification reflecting the state of a resource.

「コンテンツ」リソースの状態を反映した通知に表示されるXMLドキュメントを参照します。

3. Client Operation

3.クライアント操作

3.1. Transport Mechanism

3.1. トランスポートメカニズム

Transportation of the filter to the server is achieved by inserting the XML document, as defined in [5], in the body of the SUBSCRIBE request. Alternatively, the XML document can be uploaded to the server using means outside the scope of this document.

SUBSCRIBEリクエストのボディに、[5]で定義されるようにサーバへのフィルタの輸送は、XML文書を挿入することによって達成されます。また、XML文書は、この文書の範囲外の手段を使用してサーバーにアップロードすることができます。

3.2. SUBSCRIBE Bodies

3.2. ボディをSUBSCRIBE

SIP entities compliant with this specification MUST support the content type 'application/simple-filter+xml'.

この仕様に準拠したSIPエンティティは、コンテンツ・タイプ「アプリケーション/シンプルフィルタ+ XML」をサポートしなければなりません。

3.3. Subscriber Generating of SUBSCRIBE Requests

3.3. SUBSCRIBE要求の加入者発生

This section presents additional functionality required from the subscriber when filters are used in the bodies of the SUBSCRIBE requests. Normal operations of services (e.g., as defined in [8], [10], and [4]) are otherwise followed.

このセクションでは、フィルタは、SUBSCRIBEリクエストのボディで使用されている加入者から必要な追加機能を提供します。サービス（例えば、[8]で定義されるように[10]、及び[4]）の通常の動作は、そうでなければ続いています。

As defined in [3], the SUBSCRIBE message MAY contain a body. This body would carry filtering information. Honouring those filters is at the discretion of the notifier and might depend on local policies.

[3]で定義されるように、SUBSCRIBEメッセージは、本体を含むかもしれません。このボディは、フィルタリング情報を運ぶでしょう。これらのフィルタを尊重することは通知の裁量であり、地域の政策に依存する場合があります。

No content in the body of a SUBSCRIBE indicates to the notifier that no filter is being requested, so the notifier is instructed to send all the NOTIFY requests using the notifier's own or service-specific policy. Note that, for example, in the list case [4], the filter might have been uploaded to the server beforehand (by means outside the scope of this document).

通知は通知自身やサービス固有のポリシーを使用して、すべてのNOTIFYリクエストを送信するように指示されるように、SUBSCRIBEの体内のいかなる内容は、フィルタが要求されていない通知を示していません。例えば、リストの場合には、[4]、フィルタ（本文書の範囲外の手段によって）予めサーバにアップロードされているかもしれないことに留意されたいです。

If the body of the SUBSCRIBE includes the filter, the body MUST be of the MIME-Type 'application/simple-filter+xml'.

SUBSCRIBEのボディは、フィルタが含まれている場合、本体はMIMEタイプ「アプリケーション/シンプルフィルタ+ xmlの」でなければなりません。

3.3.1. Defining the Filtering Rules

3.3.1. フィルタリングルールの定義

Multiple filters MAY be included in one SUBSCRIBE. This is achieved by including multiple <filter> elements in the filter [5]. Each <filter> element may include a 'uri' attribute.

複数のフィルタは、1 SUBSCRIBEに含まれるかもしれません。これは、フィルタ[5]に複数の<filter>要素を含むことによって達成されます。各<フィルタ>要素は、「URI」属性を含むことができます。

A SUBSCRIBE request destined to a list URI [4] MAY include multiple filters specific to individual resources. This is achieved by including multiple <filter> elements with different URIs of resources in each of those elements. This resource specific resource-specific filter are processed first before any list specific list-specific filter, if any. The list specific list-specific filter may or may not include a URI.

リストURI宛のSUBSCRIBEリクエスト[4]個々のリソースに固有の複数のフィルタを含むかもしれません。これは、これらの要素のそれぞれにおけるリソースの異なるURIに複数の<filter>要素を含むことによって達成されます。いずれかの場合には、このリソースの特定のリソース固有のフィルタは、任意のリスト特定のリストに固有のフィルタの前に最初に処理されています。リスト特定のリスト固有のフィルタは、またはURIを含んでも含まなくてもよいです。

Furthermore, regardless of whether the SUBSCRIBE is destined to a list URI, there can only be one filter applicable to a single resource or domain within a single SUBSCRIBE. That is, each filter within a subscription MUST uniquely identify one resource or one domain.

また、関係なくSUBSCRIBEかどうかをリストURI宛され、単一のSUBSCRIBE内の単一のリソースまたはドメインに適用可能な一つのフィルタが存在することができます。つまり、サブスクリプション内の各フィルタは一意つのリソースまたは1つのドメインを識別しなければなりません。

A filter can be enabled and disabled using the 'enabled' attribute in the <filter> element, as described in [5].

[5]で説明されるようにフィルタは、<フィルター>要素の「有効」属性を使用して有効および無効にすることができます。

3.3.2. Request-URI vs. Filter URI

3.3.2. リクエストURI対URIをフィルタリング

The URI in the filter defines the target resource. For example, in the Presence service case, it is the presentity's presence information to which the filter is applied. The subscriber MAY choose to leave the URI in the filter undefined. If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI. Similarly, the subscriber MAY define a filter URI. If the Request-URI is a list URI [4], the filter URI MUST be the list URI, a sub-list URI, or resource whose URI is one of the URIs that result from a lookup, by a Resource List Server (RLS), on the Request-URI. If it is not, the filter may be ignored or may be rejected. URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).

フィルタ内のURIは、ターゲット・リソースを定義します。例えば、プレゼンスサービスの場合には、フィルタが適用されたプレゼンティティのプレゼンス情報です。加入者は、未定義のフィルターにURIを残すことを選ぶかもしれません。 URIは、フィルタ内で定義されていない場合、フィルタは、Request-URIで識別されるリソースに適用されます。同様に、加入者は、フィルタURIを定義することができます。 Request-URIがURIリストである場合、[4]、フィルタURIは、リソースリストサーバ（RLSによって、リストURI、そのURI参照起因URIの一つであるサブリストURI、またはリソースでなければなりません）、要求URIに。そうでない場合、フィルタは無視してもよいし、拒否することができます。 URIマッチングを特定の方式に対して定義されたマッチングルールに従って行われる（SIP URIマッチングルールは、RFC 3261で定義されている[2]）。

A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain. This can be used when a subscription is for a resource that is an event list with many resources from differing domains. If an individual resource-specific filter is present along with the domain filter, this resource-specific filter overrides any domain-specific filter, if any.

フィルタは、「ドメイン」属性の代わりに、「URI」属性を使用して、ドメインに対処することができます。この場合、フィルタは、そのドメイン内のリソースに適用されます。サブスクリプションは、異なるドメインからの多くのリソースを持つイベントリストでリソースのためである場合に使用することができます。個々のリソース固有のフィルタはドメインフィルタと一緒に存在する場合があれば、このリソース固有のフィルタは、任意のドメイン固有のフィルタを上書き。

3.3.3. Changing Filters within a Dialog

3.3.3. ダイアログ内のフィルタを変更します

The subscriber MAY reset or change the filter by re-issuing a new SUBSCRIBE request within the existing dialog. A SUBSCRIBE within the exiting dialog that does not contain a filter is assumed to maintain existing filters. This means that filters are persistent within a dialog and are only explicitly removed.

加入者はリセットまたは既存のダイアログ内に新しいSUBSCRIBE要求を再発行してフィルタを変更することがあります。フィルタは既存のフィルタを維持することが想定されるが含まれていません出ダイアログ内SUBSCRIBE。これは、フィルタは、ダイアログ内の永続的であるとのみ明示的に削除されることを意味します。

A subscriber requiring removal of a filter may do so by using the 'remove="true"' attribute, as defined in [5].

フィルタの除去を必要とする加入者は、[5]で定義されるように、属性「= 『true』を削除」を使用して行うことができます。

In the case where the URI in the filter is that of a list, a subscriber may override the existing filter with a filter for an individual resource that is part of the list subscribed to earlier by issuing a new SUBSCRIBE within the existing dialog and including a filter, specific for that individual resource, using a new filter ID. The new filter need not include the original filter since a filter is only removed in the manner indicated above.

フィルタ内のURIがリストの、加入者が新たな既存のダイアログ内SUBSCRIBEを含むを発行することにより、以前に加入リストの一部である個々のリソースのためのフィルタを備えた既存のフィルタを無効にすることができるということである場合に新しいフィルタのIDを使用して、その個々のリソースの特定、フィルタリング。新しいフィルタのフィルタのみを上記に示したように除去されるため、元のフィルタを含む必要はありません。

A filter is replaced by the subscriber re-issuing the filter using the same filter ID and replacing the contents of the filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the server to assume that two filters are placed for the same resource.

フィルタが同じフィルタIDを使用して、フィルターの内容を置き換えるフィルタを再発行する加入者によって置き換えられます。フィルタIDを変更し、この2つのフィルタが同じリソースのために配置されていることを前提とするサーバーを引き起こすので、URIがエラーであると考えられるリソースを保持することによりフィルタの交換。

Again, a filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].

[5]で説明したように再度、<フィルター>要素の「有効」属性を使用して、フィルタを無効にすることができ、再使用可能。

3.3.4. Subscriber Interpreting of SIP Responses

3.3.4. SIP応答の加入者通訳

The SUBSCRIBE request will be confirmed with a final response. A 200-class response indicates that the subscription has been accepted and that a NOTIFY will be sent immediately. A "200" response indicates that the subscription has been accepted and that the filter is accepted. A "202" response merely indicates that the subscription has been understood, that the content type has been accepted, and that authorization may or may not have been granted. A "202" response also indicates that the filter has not been accepted yet. The acceptance of the filter MAY arrive in a subsequent NOTIFY.

SUBSCRIBEリクエストは、最終的な応答で確認されます。 200クラスの応答は、サブスクリプションが受け入れられたことと、すぐに送信されますNOTIFYことを示しています。「200」応答は、サブスクリプションが受け入れられたことと、フィルタが受理されたことを示しています。「202」の応答は単に、サブスクリプションは、コンテンツタイプが受け入れられたことを、理解されており、その承認がまたは付与されていない可能性があることを示します。「202」応答は、フィルタがまだ受け入れられていないことを示しています。フィルタの受け入れはNOTIFY、その後に到着するかもしれません。

A non-200 class final response indicates that no subscription or dialog has been created, and no subsequent NOTIFY message will be sent. All non-200 class final responses have the same meanings and handling as described in [2] and [3].

非200クラス最終応答には、サブスクリプションまたはダイアログが作成されていないことを示し、後続のNOTIFYメッセージが送信されません。すべての非200クラス最終応答は、同じ意味を有し、に記載のように処理[2]、[3]。

Specifically, a "415" response indicates that the MIME type 'application/simple-filter+xml' is not understood by the notifier. A "488" response indicates that the content type (filter) is understood but some aspects of it were either not understood or not accepted.

具体的には、「415」応答は、MIMEタイプ「アプリケーション/シンプルフィルタ+ XMLは」通知することにより理解されていないことを示しています。「488」応答は、コンテンツタイプ（フィルタ）が理解されているが、それのいくつかの局面のいずれか受け付け理解かされなかったことを示しています。

3.4. Subscriber Processing of NOTIFY Requests

3.4. NOTIFYリクエストのサブスクライバ処理

If the 2xx response was returned for the SUBSCRIBE, the NOTIFY that follows MAY contain a body that describes the present state of the resource after the filters have been applied.

2xx応答がSUBSCRIBEに対して返された場合、それはフィルタが適用された後、リソースの現在の状態を記述する体を含むかもしれ次のNOTIFY。

If the NOTIFY indicates that a subscription has been terminated [3], the subscription is assumed to be terminated. Behaviour in such events is also described in [3].

NOTIFYをサブスクリプション[3]終了したことを示す場合、サブスクリプションが終了されているものとします。そのようなイベントにおける動作は、[3]に記載されています。

If the subscription is indicated as active, NOTIFY requests are handled as described in package-specific documents and in [3].

サブスクリプションがアクティブとして示される場合、パッケージ固有の文書に、[3]に記載のように要求が処理されるNOTIFY。

4. Resource List Server Behaviour

4.リソースリストサーバの動作

The Resource List Server is defined in [4]. This section describes how such an entity behaves in the presence of a filter in a subscription to a list.

リソースリストサーバは、[4]で定義されています。このセクションでは、このようなエンティティは、リストへのサブスクリプションにフィルタの存在下で、どのように動作するかを説明します。

4.1. Request-URI vs. Filter URI

4.1. リクエストURI対URIをフィルタリング

If the URI is not defined within the filter, the filter applies to the resource list identified in the Request-URI of the SUBSCRIBE request. This results in the filters being applied to all the notifications that the RLS issues to this subscription. The same processing applies to a filter that defines a URI that matches the request-URI of the SUBSCRIBE request. That is, the filter applies to all notifications that the RLS issues to this subscription.

URIは、フィルタ内で定義されていない場合、フィルタは、SUBSCRIBEリクエストのRequest-URIで特定されたリソースのリストに適用されます。フィルタのこの結果は、このサブスクリプションのすべての通知RLSの問題に適用されています。同様の処理は、SUBSCRIBEリクエストのリクエストURIと一致するURIを定義するフィルタに適用されます。つまり、フィルタは、すべての通知に適用されるこのサブスクリプションにRLSの問題。

If the URI indicated by the filter is for one resource whose URI is one of the URIs that result from a lookup by the RLS on the Request-URI, the filter for that particular resource is extracted and propagated in the SUBSCRIBE request sent to that resource. It is possible to have more than one filter in a SUBSCRIBE request body, and therefore a filter specific to a resource MUST be extracted and only that one is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@example.com", where "bob@example.com" is a resource belonging to that list, and the URI in a filter is "sip:bob@example.com", the filter specific for Bob is extracted and placed in the body of the SUBSCRIBE sent to "bob@example.com".

フィルタによって示されるURIは、一つのリソースそのURIがRequest-URIにRLSによってルックアップに起因するURIの一つであるためである場合、その特定のリソース用のフィルタが抽出され、そのリソースに送信されるSUBSCRIBEリクエストに伝播されます。 SUBSCRIBEリクエストのボディに複数のフィルタを有することが可能であり、したがって、リソースに特有のフィルタが抽出しなければならないだけ1つが伝播されます。 SUBSCRIBE中のRequest-URIの値が「SIP：mybuddies@example.com」を有する場合、例えば、「bob@example.com」リソースがそのリストに属しており、フィルタ内のURIは、「SIPです。 bob@example.com」、ボブのフィルタ特定を抽出し、SUBSCRIBEに送らの本体内に配置されている『』 bob@example.com。

If the URI indicated by the filter is for one resource whose URI is NOT under the RLS administrative control, the RLS propagates the filter to all the fanned out subscriptions. This is to accommodate the scenario where the subscriber knows that there are sub-lists in the event list that are under a different administrative domain from that where the original subscription was sent, and the subscriber wishes to set a filter for a resource in that sub-list.

フィルタによって示されたURIは、そのURI RLS行政管理下にない一つのリソースに対するものである場合、RLSは、すべてのファンアウトサブスクリプションにフィルタを伝播します。これは、加入者が、元のサブスクリプションが送信されたものとは異なる管理ドメインの下にあるイベントリストでサブリストがあることを知っているシナリオに対応することであり、加入者は、そのサブ内のリソースのためのフィルタを設定したいです-リスト。

If the URI indicated by the filter is for one resource whose URI is under the RLS administrative control but is not part of the resource list that the subscription was addressed to, the filter is not propagated. In this case, it is the RLS's responsibility to make sure that this filter is applied to notifications issued, if information about that resource is present.

URIは、フィルタによって示された場合は、そのURI RLSの管理制御下にあるが、サブスクリプションが、フィルタが伝播されないに宛てたリソースリストの一部ではない一つのリソースのためです。この場合、そのリソースに関する情報が存在する場合、このフィルタは、発行された通知に適用されていることを確認するためにRLSの責任です。

For example: If we have 2 lists, each located on its own RLS:

例えば：私たちは2つのリストを持っている場合は、それぞれが独自のRLSにあります：

List1 (list1@example.com) on RLS1 has: bob@example.com

RLS1上のList1は（list1@example.com）があります。bob@example.com

list2@biloxi.com

ぃｓｔ２＠びぉぃ。こｍ

List2 on RLS2 has: alice@biloxi.com sarah@example.com (Note: list2 is a resource in list1)

RLS2上LIST2がありますalice@biloxi.com sarah@example.com（注：LIST2はリスト1内のリソースです）

RLS1 receives the following SUBSCRIBE request (the SUBSCRIBE is addressed to list1 and contains 2 filters: one for sarah@example.com and the other for alice@biloxi.com):

RLS1は、以下の（：sarah@example.com用とalice@biloxi.comのために他のSUBSCRIBEリスト1宛と2つのフィルタが含まれている）SUBSCRIBEリクエストを受信します。

SUBSCRIBE sip:List1@example.com SIP/2.0 ... <?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <ns-bindings> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/> </ns-bindings> <filter id="999" uri="sip:sarah@example.com"> <what> <include type="namespace"> urn:ietf:params:xml:ns:pidf</include> <exclude> //pidf:tuple/pidf:note</exclude> </what> </filter> <filter id="8439" uri="sip:alice@biloxi.com"> <what> <include> //pidf:tuple/pidf:status/pidf:basic</include> </what> </filter> </filter-set>

一口にSUBSCRIBE：List1@example.com SIP / 2.0 ...の<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：simple-フィルタ "> <NS-バインディング> <NS-結合プレフィックス=" PIDF "URN = "URN：IETF：paramsは：XML：NS：PIDF"/> </ NS-バインディング> <フィルタID = "999" URI =" SIP：sarah@example.com "> <何を> <タイプ=含める" 名前空間 "> URN：IETF：のparams：XML：NS：PIDF </ include>の<除外> // PIDF：タプル/ PIDF：</除外に注意を> </何> </フィルタ> <フィルタID = "8439" のuri = "一口：alice@biloxi.com"> <何を> <> // PIDF含まれます：タプル/ PIDF：ステータス/ PIDF：基本的に</含ま> </何> </フィルタ> </フィルタリング設定>

RLS1 fans out subscriptions to resources on list1. The text above suggests that if a filter is destined to a resource that is not part of the list and is outside the administrative domain of an RLS, then that filter is propagated. The rest are consumed. In our example, only the filter to alice@biloxi.com is propagated since biloxi.com is not under the administrative domain of RLS1. The filter to sarah@example.com is consumed, and RLS1 needs to apply that filter to notifications it receives.

RLS1ファンアウトリスト1上のリソースへのサブスクリプションを。テキストは、上記のフィルタはリストの一部ではなく、RLSの管理ドメイン外にあるリソースを宛先としている場合は、そのフィルタが伝播されることを示唆しています。残りは消費されています。 biloxi.comがRLS1の管理ドメイン下にないため、この例では、alice@biloxi.comにのみフィルタが伝播されます。 sarah@example.comにフィルタが消費され、RLS1は受け取った通知にそのフィルタを適用する必要があります。

URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).

URIマッチングを特定の方式に対して定義されたマッチングルールに従って行われる（SIP URIマッチングルールは、RFC 3261で定義されている[2]）。

A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain, and the RLS MUST NOT apply filters to any notifications it sends. Instead, it MUST forward the filter with all fanned-out subscriptions to the notifiers.

フィルタは、「ドメイン」属性の代わりに、「URI」属性を使用して、ドメインに対処することができます。この場合、フィルタは、そのドメイン内のリソースに適用され、RLSは、送信するすべての通知にフィルタを適用してはなりません。その代わりに、ノーティファイアへのすべての扇形に広がるアウトサブスクリプションでフィルタを転送する必要があります。

As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In such circumstances, an RLS MUST check that there are no filters addressed to the same resource or domain, and if there are, it MUST reject the SUBSCRIBE request with a "488" error response.

セクション3.3.1に示すように、複数のフィルタは、SUBSCRIBEリクエストに存在することができます。セクション3.3.3に示すように、フィルタはまた、追加または変更することができます。このような状況では、RLSにはフィルタが同じリソースまたはドメイン宛て、および存在する場合、それは「488」のエラー応答でSUBSCRIBE要求を拒絶しなければなりませんがないことをチェックしなければなりません。

4.2. Changing Filters within a Dialog

4.2. ダイアログ内のフィルタを変更します

If an RLS receives a subscription refresh request with no filters specified (empty payload), the RLS assumes that the client does not wish to update the filters. If an RLS receives a subscription refresh with a filter containing the 'remove="true"' attribute, as defined in [5], the RLS assumes that the client is removing that filter identified by the filter ID.

RLSは、指定したフィルタなし（空のペイロード）とサブスクリプションの更新要求を受信した場合、RLSは、クライアントがフィルタを更新したくないことを前提としています。 RLSは、「削除= 『true』を」属性を含むフィルターとサブスクリプションの更新を受信した場合に定義されるように、[5]、RLSは、クライアントが、フィルタのIDで識別されるそのフィルタを削除していることを前提としています。

If an RLS receives a subscription refresh request with a filter that already exists (i.e., having the same filter ID), the RLS interprets it as a replacement of the existing filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the RLS to assume that two filters are in place for the same resource.

RLSが既に存在するフィルタ（すなわち、同一のフィルタIDを有する）と、サブスクリプションの更新要求を受信した場合、RLSは、既存のフィルタの代替としてそれを解釈します。これは、RLSは、2つのフィルタが同じリソースのための場所であると仮定する原因となるため、リソースURIをフィルタIDを変更し、維持することによって、フィルタを交換すると、エラーとみなされます。

A filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].

[5]で説明されるようにフィルタは、<フィルター>要素の「有効」属性を使用して無効にし、再度有効にすることができます。

5. Server Operation

5.サーバーの操作

5.1. NOTIFY Bodies

5.1. ボディをNOTIFY

SIP entities compliant with this specification MUST support content-type 'application/simple-filter+xml'.

この仕様に準拠したSIPエンティティは、「アプリケーション/シンプルフィルタ+ xmlの」コンテンツ・タイプをサポートしなければなりません。

5.2. Notifier Processing of SUBSCRIBE Requests

5.2. SUBSCRIBE要求の通知処理

This section presents additional functionality required from the notifier when filters are used in the bodies of the SUBSCRIBE requests. Normal package-specific functionality is otherwise followed.

このセクションでは、フィルタは、SUBSCRIBEリクエストのボディで使用されている通知から必要な追加機能を提供します。通常のパッケージ固有の機能は、それ以外の場合は続いています。

The notifier will examine the Content-Type header field and will return a 415 response if it does not understand the content type 'application/simple-filter+xml'.

通知は、Content-Typeヘッダフィールドを調べますと、それはコンテンツ・タイプ「アプリケーション/シンプルフィルタ+ XML」を理解していない場合は415応答を返します。

A 200-class response indicates that the subscription has been accepted, and the NOTIFY will be sent immediately. A "200" response indicates that the subscription has been accepted, the user is authorized, and the filter is accepted. A "202" response merely indicates that the subscription has been understood, but that the authorization may or may not have been granted. A "202" response also indicates that the filters have not been accepted yet. The acceptance of the filters MAY arrive in a subsequent NOTIFY.

200クラスの応答は、サブスクリプションが受け入れられたことを示し、およびNOTIFYすぐに送信されます。「200」の応答は、ユーザーが許可され、サブスクリプションが受け入れられたことを示し、およびフィルタが受け入れられています。「202」の応答は、単にサブスクリプションが理解されていることを示しているが、許可がまたは付与されていない場合があること。「202」の応答はまた、フィルターはまだ受け入れられていないことを示しています。フィルタの受け入れはNOTIFY、その後に到着するかもしれません。

Procedures described in Section 5.4 are followed if an error is encountered.

エラーが発生した場合、セクション5.4で説明した手順が続いています。

As indicated in Section 3.3.1, multiple filters can be present in a SUBSCRIBE request. Filters can also be added or modified as indicated in Section 3.3.3. In such circumstances, a server MUST check that there are no filters addressed to the same resource or domain, and if they are, it MUST reject the SUBSCRIBE request with a "488" error response.

セクション3.3.1に示すように、複数のフィルタは、SUBSCRIBEリクエストに存在することができます。セクション3.3.3に示すように、フィルタはまた、追加または変更することができます。このような状況では、サーバーにはフィルタが同じリソースまたはドメイン宛て、彼らがしている場合、それは「488」のエラー応答でSUBSCRIBE要求を拒絶しなければなりませんがないことをチェックしなければなりません。

5.2.1. Request-URI vs. Filter URI

5.2.1. リクエストURI対URIをフィルタリング

The subscriber may have chosen to leave the URI in the filter undefined. If the URI is not defined within the filter, the filter applies to the resource identified in the Request-URI.

加入者は、未定義のフィルタにURIを残すように選択されていてもよいです。 URIは、フィルタ内で定義されていない場合、フィルタは、Request-URIで識別されるリソースに適用されます。

Similarly, the subscriber may have chosen to include a URI in the filter. In this case, the filter applies to all notifications sent with content associated with the resource with that URI for this subscription. If the Request-URI and the URI in the filter do not match, the filter may be ignored or rejected. URI matching is done according to the matching rules defined for a particular scheme (SIP URI matching rules are defined in RFC 3261 [2]).

同様に、加入者は、フィルタ内のURIを含むように選択されていてもよいです。この場合、フィルタは、このサブスクリプションのためにそのURIを持つリソースに関連付けられたコンテンツを送信されたすべての通知に適用されます。フィルター内のRequest-URIとURIが一致しない場合、フィルタは無視または拒否することができます。 URIマッチングを特定の方式に対して定義されたマッチングルールに従って行われる（SIP URIマッチングルールは、RFC 3261で定義されている[2]）。

A filter may also be addressed to a domain using the 'domain' attribute instead of the 'uri' attribute. In this case, the filter applies to resources in that domain. A notifier MUST ignore any filter using a 'domain' attribute containing a domain for which this notifier is not responsible. The notifier MUST NOT apply such a filter to any notification it sends. Notifiers belonging to the domain MUST apply the filter to all notifications it sends for that subscription, unless policy dictates otherwise.

フィルタは、「ドメイン」属性の代わりに、「URI」属性を使用して、ドメインに対処することができます。この場合、フィルタは、そのドメイン内のリソースに適用されます。通知は、この通知は責任を負いませんいるドメインを含む「ドメイン」属性を使用して任意のフィルタを無視しなければなりません。通知は、送信するすべての通知に、このようなフィルタを適用してはなりません。ポリシーが指示しない限り、ドメインに属しているのNotifierは、それがそのサブスクリプションのために送信するすべての通知にフィルタを適用しなければなりません。

5.2.2. Changing Filters within a Dialog

5.2.2. ダイアログ内のフィルタを変更します

If a server receives a subscription refresh request with no filters specified (empty payload), it assumes that the client does not wish to update the filters. If it receives a subscription refresh with a filter containing the 'remove="true"' attribute, as defined in [5], the server assumes that the client is removing the filter identified by the filter ID.

サーバが指定されていないフィルタを使用してサブスクリプションのリフレッシュ要求（空のペイロード）を受信した場合、それは、クライアントがフィルタを更新したくないことを前提としています。それは削除= 『true』を '属性を含むフィルターとサブスクリプションの更新を受信した場合に定義されるように、[5]、サーバーは、クライアントが、フィルタのIDで識別されるフィルタを削除していることを前提としています。

If the server receives a subscription refresh request with a filter that already exists (i.e., having the same filter ID), it interprets it as a replacement of the existing filter. Replacing a filter by changing the filter ID and keeping the resource URI is considered an error since this causes the server to assume that two filters are placed for the same resource.

サーバがすでに存在するフィルタ（すなわち、同一のフィルタIDを有する）、それは既存のフィルタの代替としてそれを解釈すると、サブスクリプションの更新要求を受信した場合。フィルタIDを変更し、この2つのフィルタが同じリソースのために配置されていることを前提とするサーバーを引き起こすので、URIがエラーであると考えられるリソースを保持することによりフィルタの交換。

5.3. Notifier Generating of NOTIFY Requests

5.3. NOTIFYリクエストの通知の生成

Upon receiving the SUBSCRIBE with the filter, the notifier SHOULD retain the filter as long as the subscription persists. The filter MAY be incorporated within an existing subscription (in an active dialog) by sending a re-SUBSCRIBE that includes the filter in the body.

フィルタとSUBSCRIBE受信すると、通知があれば、サブスクリプションが持続するようにフィルタを保持すべきです。フィルタは、それが体内のフィルタを含む再SUBSCRIBE送信することによって、（アクティブなダイアログで）既存のサブスクリプション内に組み込むことができます。

If the response sent to the SUBSCRIBE was a "202" and the "202" was chosen because the filter could not be accepted that time, the NOTIFY MAY be used to terminate the subscription if the filter is found unacceptable.

SUBSCRIBEに送信された応答は「202」と「202」フィルタは、その時間を受け入れることができなかったので、選ばれたのだった場合、フィルタが受け入れられない発見された場合は、サブスクリプションを終了するために使用されるかもしれ通知します。

As described in [3], the NOTIFY message MAY contain a body that describes the state of the resource. This body is in one of the formats listed in the Accept header field of the SUBSCRIBE, or in the package-specific default if the Accept header field is omitted.

[3]に記載されているように、NOTIFYメッセージは、リソースの状態を記述する体を含むかもしれません。この本体は、Acceptヘッダーフィールドが省略された場合、またはパッケージ固有のデフォルトにSUBSCRIBEのAcceptヘッダーフィールドにリストされている形式のいずれかです。

Based on the contents of a filter, the following processing occurs:

フィルタの内容に基づいて、以下の処理が行われます。

o A filter with only a <what> element will result in sending the requested resource state information in that <what> element whenever there is a change in the resource state.

Oとフィルタだけ要素がその中に要求されたリソース状態情報リソースの状態に変化があるたびに、<もの>要素を送信することになる<もの>。

o A filter with only a <trigger> element will result in sending all resource state information whenever there is a change in the resource state that matches the triggers.

Oのみ<トリガー>を有するフィルタエレメントは、トリガーを一致リソースの状態に変化があるたびにすべてのリソースの状態情報を送信することになります。

o A filter with <what> and <trigger> elements will result in sending the requested resource state information in that <what> element whenever there is a change in the resource state that matches the triggers.

<もの>でフィルターOおよび<トリガー>要素は、トリガーを一致リソースの状態に変更があるたびに、その<もの>要素内の要求されたリソースの状態情報を送信することになります。

When a filter is disabled (by setting the 'enabled' attribute to "false"), it means the same thing as the absence of that filter. That is, all state and state changes are reported by issuing a notification to the subscriber (assuming there are no other filters).

フィルタは（「有効」属性を「false」に設定することで）無効になっている場合は、そのフィルタが存在しない場合と同じことを意味します。つまり、すべての状態及び状態変化は、（他のフィルタが存在しないと仮定して）加入者に通知を発行することによって報告されています。

When a filter is re-enabled (by setting the 'enabled' attribute to "true" or by omitting the 'enabled' attribute), the notifier behaves as if the filter has just been placed by the SUBSCRIBE request enabling it. Immediate NOTIFY rules, as stated in Section 5.3.1, apply.

フィルタが再び有効にされている場合（「真」または「有効」属性を省略してまで「有効」属性を設定することにより）フィルタはそれを有効にするSUBSCRIBEリクエストによって配置されているかのように、通知が動作します。 5.3.1項で述べたように即時には、ルールをNOTIFY、適用されます。

5.3.1. Generation of NOTIFY Contents

5.3.1. NOTIFYコンテンツの生成

If the NOTIFY being sent is the one sent immediately after a 2xx response to the original SUBSCRIBE, its contents MUST be populated according to the filter <what> element, unless the processing of the filters will take too long or the NOTIFY request is following a "202" response to the SUBSCRIBE request and is terminating the subscription. In the case that the filter is taking too long to process, the NOTIFY request being sent may be empty or may be populated with a pre-configured value as authorised to that subscriber. If applying the filter results in no content to be delivered, the NOTIFY MUST be sent with empty contents. If the filter contains <trigger> elements, the notifier ignores the trigger values when generating the first NOTIFY request.

NOTIFY送信されている場合は1がSUBSCRIBE元に2xx応答の直後に送信されるフィルタの処理は時間がかかりすぎるでしょうかNOTIFYリクエストは、次のされていない限り、その内容は、フィルタ<何を>要素に応じて居住しなければなりませんSUBSCRIBEリクエストに「202」応答はサブスクリプションを終了しています。フィルタが処理に時間がかかりすぎてした場合には、送信されるNOTIFYリクエストは空であってもよいし、その加入者に許可されたように、予め設定された値で埋めてもよいです。配信すべきコンテンツのフィルタ結果を適用する場合、NOTIFYは空の内容で送信されなければなりません。フィルタは、<トリガー>要素が含まれている場合は最初のNOTIFYリクエストを生成するときに、通知がトリガ値を無視します。

The input to the content filter is a package-specific XML document (e.g., [7] and [9]) derived according to the package-specific specifications, (e.g., [8] and [10]).

コンテンツフィルタへの入力は、パッケージ固有のXML文書である（例えば、[7]、[9]）パッケージ固有の仕様に応じて誘導される（例えば、[8]、[10]）。

The content is filtered according to the expressions in the <what> element of the filter. The expression indicates the delivered XML elements and/or attributes. Prefixes of the namespaces of the items of the XML document to be filtered must be expanded before applying the filter to the items.

コンテンツは、フィルタの<もの>要素内の式に従ってフィルタリングされます。式は配信XML要素および/または属性を示します。フィルタリングされるXML文書のアイテムの名前空間の接頭辞は、項目にフィルタを適用する前に展開する必要があります。

The expression directly states the XML elements and attributes to be delivered in the NOTIFY, along with their values. In addition to the selected contents, the namespaces of all the selected items are also included in the NOTIFY. The XML elements and/or attributes indicated by the expression in the <what> element must be items that the subscriber is authorised to see. If they are not, the notifier policy dictates the behaviour of the notifier (which can ignore the filter, parts of the filter, or reject the filter completely). Implementers need to carefully consider such an implementation decision; the subscriber may not be aware of the authorised contents and therefore most likely will include a filter requesting unauthorised contents. It is therefore RECOMMENDED that notifiers just ignore the parts of the filter that are requesting unauthorised info (i.e., the filter in the <filter> element where the unauthorised contents are requested is ignored). If polite blocking is used by the notifier, the notifier may choose to deliver notifications containing bogus information in the unauthorised elements or attributes and applying the filter afterwards.

式は、直接XML要素を述べ、その値と一緒に、NOTIFYで配信される属性。選択された内容に加えて、選択されたすべてのアイテムの名前空間もNOTIFYに含まれています。 XML要素および/または構成要素は、加入者が見ることが許可されている項目でなければならない<何を>での発現によって示された属性。そうでない場合、通知ポリシーには、（フィルタ、フィルタの一部を無視する、または完全にフィルタを拒否することができる）通知の動作を指示します。実装者は慎重に、このような実装の決定を検討する必要があります。加入者は、許可の内容を認識していない可能性があるため、最も可能性の高い不正な内容を要求するフィルタが含まれます。したがって、通知機能がちょうど（即ち、不正なコンテンツが要求されている<フィルター>におけるフィルタ要素が無視される）不正な情報を要求しているフィルタの部分を無視することが推奨されます。丁寧なブロッキングは通知で使用されている場合、通知は、不正な要素や属性で偽の情報を含む、その後、フィルタを適用する通知を配信することもできます。

The resultant XML document MUST be well formed and valid according to the XML schema. This means that all mandatory elements and attributes, along with their values, MUST be included in the XML document regardless of the expression. In other words, if the result of applying a filter on an XML document is a non-valid XML document, the notifier MUST add elements and attributes, along with their values, from the original XML document into the newly formulated one in order for it to be valid.

結果のXMLドキュメントはよくXMLスキーマに従って形成され、有効でなければなりません。これは、すべての必須要素と属性は、その値とともに、関係なく、式のXML文書に含まれなければならないことを意味しています。 XML文書にフィルタを適用した結果が非有効なXML文書である言い換えれば、通知は、ためには、元のXML文書から新たに処方一つに、それらの値と一緒に、要素および属性を追加しなければなりません有効にします。

5.3.2. Handling of Notification Triggering Rules

5.3.2. 通知トリガルールの取り扱い

There can be several <trigger> elements inside one <filter> element. If the criteria for any of the <trigger> elements are satisfied, a NOTIFY SHOULD be generated.

1 <フィルタ>要素内のいくつかの<トリガー>要素が存在する場合があります。 <トリガー>のいずれかの基準は、要素が満たされた場合、NOTIFYが生成されるべきです。

The items (XML elements and/or attributes) indicated by the expression in the <changed> element, <added> element, or <removed> element must be items that the subscriber is authorised to access. If they are not, the notifier policy dictates the behaviour of the notifier (which can ignore the filter, parts of the filter, or reject the filter completely).

<変更>要素、<追加>要素、または<除去>要素内での発現によって示される商品（XML要素および/または属性）は、加入者がアクセスを許可されている項目でなければなりません。そうでない場合、通知ポリシーには、（フィルタ、フィルタの一部を無視する、または完全にフィルタを拒否することができる）通知の動作を指示します。

5.4. Handling Abnormal Cases

5.4. 異常なケースの取り扱い

In case of an invalid filter definition where the XML document of the filter is not aligned with the XML schema of the filter format [5], the notifier rejects the SUBSCRIBE request with a "488" response. A Warning header field in the response may give a better indication as to why the filters were not accepted. If the subscription was accepted with a "202" response but the invalid filter was discovered after that, a NOTIFY with a subscription-state of value 'terminated' is sent. An event-reason-value "badfilter", introduced here, of subexp-params [3] MAY be included.

フィルタのXML文書をフィルタ形式[5]のXMLスキーマと整列していない無効なフィルタ定義の場合には、通知は、「488」応答を有するSUBSCRIBE要求を拒否する。応答に警告ヘッダフィールドはフィルタが受け入れられなかった理由として、より良い指標を与えることができます。サブスクリプションが「202」応答で受け入れられましたが、無効なフィルタがその後発見された場合は、値が「終了」のサブスクリプション状態でNOTIFY送信されます。 subexp-のparams [3]のここで紹介した "badfilter" イベント-理由-値は、含まれるかもしれません。

In case of an erroneous expression in the filter definition, the notifier either ignores the filter definition or terminates the subscription.

フィルタ定義における誤った表現の場合は、通知は、フィルタ定義を無視するか、サブスクリプションを終了どちらか。

If a <what> or <trigger> element is empty, the notifier proceeds as if the element did not exist.

<何を>または<トリガー>要素が空の場合、要素かのように通知進み、存在しませんでした。

6. XML Document Validation

6. XMLドキュメントの検証

The subscriber of the filter MUST ensure that the XML document inserted as the SUBSCRIBE request body is well formed and valid. The subscriber MUST NOT insert any extension elements or attributes into the XML document unless it has access to the extension schema and can validate the XML document. The XML document notifier MAY validate the XML document according to the schemas, including extension schemas, to which it has access that are applicable to this XML document.

フィルタの加入者は、SUBSCRIBEリクエストのボディとして挿入XML文書が十分に形成され、有効であることを確実にしなければなりません。それは拡張スキーマへのアクセス権を持ち、XML文書の妥当性を検証することができない限り、加入者は、XMLドキュメントに任意の拡張要素や属性を挿入してはなりません。 XMLドキュメントの通知は、拡張スキーマを含むスキーマに従ってXML文書を検証することができる、それはこのXML文書に適用可能なアクセス権を持っているの。

7. Examples

7.例

The following sections include filtering examples for Presence and Watcher Information. The format of filter is according to [5].

次のセクションでは、プレゼンスとウォッチャー情報のフィルタリング例が挙げられます。フィルタの形式は、[5]に従います。

7.1. Presence Specific Examples

7.1. プレゼンス具体例

This section describes three use cases where the presence information filtering solution is utilised [8]. In the first use case, the watcher is interested in getting messaging-specific information of a certain presentity. In the second use case, the watcher is interested in getting information about the communication means and contact addresses on which the presentity is currently available for communication. The third case shows how a presentity can request triggers to receive notifications.

このセクションでは、[8]プレゼンス情報フィルタリングソリューションが利用される3つのユースケースを説明しています。最初の使用の場合には、ウォッチャーは、特定のプレゼンティティのメッセージング固有の情報を得ることに興味があります。第2の使用ケースでは、ウォッチャは、プレゼンティティの通信のために現在利用可能なされている通信手段と連絡先に関する情報を得ることに興味があります。第三のケースはプレゼンが通知を受信するためのトリガを要求できる方法を示しています。

Below is the presentity's presence information in PIDF [7]. It includes two tuples: one for the instant messaging and another for the voice-related information.

以下はPIDF [7]でプレゼンティティのプレゼンス情報があります。音声関連情報については、インスタントメッセージング用と別：それは2つのタプルが含まれています。

<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="432sd"> <status> <basic>closed</basic> </status> <rpid:class>IM</rpid:class> <contact>im:presentity@example.com</contact> </tuple> <tuple id="thr76jk"> <status> <basic>open</basic> </status> <rpid:class>voice</rpid:class> <contact>tel:2224055555@example.com</contact>

<？xml version = "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：RPIDは=「URN：IETF：paramsは：XML：NS：PIDF ：RPID」エンティティ= "SIP：presentity@example.com"> <タプルIDは= "432sd"> <状態> <基本> </塩基性> </状態>閉鎖<RPID：クラス> IM </ RPID：クラス> <コンタクト> IM：presentity@example.com </接触> </タプル> <タプルID = "thr76jk"> <状態> <基本>開く</塩基性> </状態> <RPID：クラス>音声</ RPID ：クラス> <連絡先> TEL：2224055555@example.com </連絡先>

            </tuple>
         </presence>

7.1.1. Subscriber Requests Messaging-Related Information

7.1.1. 加入者は、メッセージング関連の情報を要求します

The subscriber initiates a subscription to the presentity's messaging (MMS, IM, and SMS) related presence information. The subscription includes the content limiting filter.

加入者はプレゼンのメッセージング（MMS、IM、およびSMS）に関連するプレゼンス情報へのサブスクリプションを開始します。サブスクリプションは、フィルタを制限する内容を含んでいます。

The filtered content is indicated with an expression. This expression selects the <basic> element and all the parent elements (i.e., the <status>, the <tuple>, and its root element), the <class> element, and the <contact> element. The filter matches if the <class> element contains "MMS", "SMS", or "IM".

濾過コンテンツは式で示されています。この式は、<基本>要素およびすべての親要素（すなわち、<状態>、<タプル>、およびそのルート要素）、<クラス>要素と<接点>要素を選択します。フィルタは、<class>要素は、 "MMS"、 "SMS"、または "IM" が含まれている場合に一致します。

In this case, the notification includes the contents of the tuple that has the value "IM" in its <class> element.

この場合、通知は、<class>要素の値「IM」を有するタプルの内容を含みます。

SUBSCRIBE request from the subscriber including filter:

フィルタを含む加入者からの要求をSUBSCRIBE：

SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...

：<presentity@example.com SIP：>：presentity@example.com経由：SIP / 2.0 / TCP client.example.com:5060;branch=z9hG4bKxjfdsjfkにSIPをSUBSCRIBE <一口：watcher@example.com>;タグ：12341111コールID：CSEQ 32432udfidfjmk342：1は、SUBSCRIBEの有効期限：3600イベント：プレゼンス連絡先：<SIP：watcher@client.example.com>のContent-Type：アプリケーション/シンプルフィルタ+ XMLコンテンツ-長さ：...

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <ns-bindings> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/> <ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/> </ns-bindings> <filter id="123" uri="sip:presentity@example.com"> <what> <include type="xpath"> //pidf:tuple[rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"]/pidf:status/pidf:basic </include> <include type="xpath"> //pidf:tuple[rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"]/rpid:class

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター"> <NS-バインディング> <プレフィックスをNS-結合= "PIDF" URN = "URN：IETF：paramsは：XML：NS：PIDF" /> <NS-結合プレフィックス= "RPID" URN = "URN：IETF：paramsは：XML：NS：PIDF：RPID" /> </ NS-バインディング> <フィルタID = "123" URI = "SIP：presentity@example.com"> <何を> <タイプ= "のXPath"> // PIDF含む：タプル[RPID：クラス= "IM" またはRPIDを：クラス= "SMS" またはRPID：クラス= "MMS"] / PIDF：ステータス/ PIDF：基本的な</ include>の// PIDF <タイプ= "XPathの" include>のタプル[RPID：クラス= "IM" またはRPIDを：クラス= "SMS" またはRPID：クラス= "MMS"] / RPID：クラス

</include> <include type="xpath"> //pidf:tuple[rpid:class="IM" or rpid:class="SMS" or rpid:class="MMS"]/pidf:contact </include> </what> </filter> </filter-set>

</含ま> // PIDF <TYPE = "XPathの" 含める>タプル[RPID：クラス= "IM" またはRPID：クラス= "SMS" またはRPID：クラス= "MMS"] / PIDF：コンタクト</含んを> </どのような> </フィルタ> </フィルタリング設定>

Notification to the subscriber:

加入者への通知：

NOTIFY sip:watcher@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: <sip:watcher@example.com>;tag:12341111 From: <sip:presentity@example.com>;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Event: Presence Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...

タグ;：<watcher@example.com SIP：>：12341111から：<SIP watcher@client.example.com SIP / 2.0経由：SIP / 2.0 / TCP presence.example.com:5060;branch=z9hG4bKxjfderにSIPをNOTIFY ：presentity@example.com>;タグ：232321コールID：32432udfidfjmk342 CSEQ：1 NOTIFYイベント：プレゼンスサブスクリプションのステート：アクティブ;有効期限が切れる= 3599お問い合わせ：SIP：presentity@server.example.comのContent-Type：アプリケーション/ PIDF + XMLコンテンツ-長さ：...

7.1.2. Subscriber Fetches Information about "Open" Communication Means

7.1.2. 加入者は、「オープン」の通信手段に関する情報を取得します

The subscriber makes a subscription to the presentity's available communication means. The subscription includes the content-limiting filter.

加入者はプレゼンの利用可能な通信手段へのサブスクリプションを作成します。サブスクリプションは、コンテンツ制限フィルタを含んでいます。

濾過コンテンツは式で示されています。この式は、<基本>要素およびすべての親要素（すなわち、<状態>、<タプル>、およびそのルート要素）、<クラス>要素と<接点>要素を選択します。 <基本>要素の値が「オープン」である場合、フィルタが一致します。

In this case, the notification returns the contents of the tuple that has the value "open" inside the <status> element.

この場合、通知は、<状態>要素内に「オープン」の値を有するタプルの内容を返します。

SUBSCRIBE request from the subscriber including filter:

フィルタを含む加入者からの要求をSUBSCRIBE：

SUBSCRIBE sip:presentity@example.com SIP/2.0 Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence Contact: <sip:watcher@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...

：<presentity@example.com SIP：>：<SIP：watcher@example.com presentity@example.com SIP / 2.0経由：SIP / 2.0 / TCP client.example.com:5060;branch=z9hG4bKxjfdsjfkにSIPをSUBSCRIBE >;タグ：12341111コールID：32432udfidfjmk342 CSEQ：1 SUBSCRIBE有効期限：3600イベント：プレゼンス連絡先：<SIP：watcher@client.example.com>のContent-Type：アプリケーション/シンプルフィルタ+ XMLコンテンツ長.. 。

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <ns-bindings> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/> <ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid"/> </ns-bindings> <filter id="123" uri="sip:presentity@example.com"> <what> <include type="xpath"> //pidf:tuple/pidf:status[pidf:basic="open"]/pidf:basic </include> <include type="xpath"> //pidf:tuple[pidf:status/pidf:basic="open"]/rpid:class </include> <include type="xpath"> //pidf:tuple[pidf:status/pidf:basic="open"]/pidf:contact </include> </what> </filter> </filter-set>

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター"> <NS-バインディング> <プレフィックスをNS-結合= "PIDF" URN = "URN：IETF：paramsは：XML：NS：PIDF" /> <NS-結合プレフィックス= "RPID" URN = "URN：IETF：paramsは：XML：NS：PIDF：RPID" /> </ NS-バインディング> <フィルタID = "123" URIは= "SIP：presentity@example.com"> <> <含むどのようなタイプ= "のXPath"> // PIDF：タプル/ PIDF：ステータス[PIDF：ベーシック= "オープン"] / PIDF：基本的な</ include>の<タイプ=含む" のXPath "> // PIDF：タプル[PIDF：ステータス/ PIDFを基本=" オープン "] / RPID：クラス</含ま> <含むタイプ=" のXPath "> // PIDF：タプル[PIDF：ステータス/ PIDF：ベーシック=" "オープン] / PIDF：コンタクト</ include>の</何> </フィルタ> </フィルタセット>

Notification to the subscriber:

加入者への通知：

Subscription-State: active; expires=3599 Contact: sip:presentity@server.example.com Content-Type: application/pidf+xml Content-Length: ...

サブスクリプション・ステート：アクティブ;有効期限が切れる= 3599お問い合わせ：SIP：presentity@server.example.comのContent-Type：アプリケーション/ PIDF + XMLコンテンツ-長さ：...

<？xml version = "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：RPIDは=「URN：IETF：paramsは：XML：NS：PIDF ：RPID」エンティティ= "SIP：presentity@example.com"> <タプルID = "thr76jk"> <状態> <基本>開く</塩基性> </状態> <RPID：クラス>音声</ RPID：クラス> <コンタクト> TEL：2224055555@example.com </接触> </タプル> </プレゼンス>

7.1.3. Subscriber Requests Notifications When Presentity's Status Changes

7.1.3. 加入者は、通知を要求するとプレゼンのステータスの変更

The subscriber subscribes to the presentity, specifying in the filter that it wants notifications only when the <basic> element has changed to value "open".

加入者は、それは、<基本>要素は、「オープン」の値に変更されたときにのみ通知を望んでいるフィルタに指定して、プレゼンに加入します。

SUBSCRIBE request from the subscriber including filter:

フィルタを含む加入者からの要求をSUBSCRIBE：

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <ns-bindings> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/> </ns-bindings> <filter id="123" uri="sip:presentity@example.com"> <trigger> <changed from="closed" to="open"> /pidf:presence/pidf:tuple/pidf:status/pidf:basic

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

</changed> </trigger> </filter> </filter-set>

</フィルタ> </フィルタセット> </トリガ> </変更>

At some point during the subscription, a second PIDF document is created with both tuples having a status of "closed":

購読中のある時点で、第二PIDF文書は、両方のタプルが「閉」の状態を持って作成されます。

<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="432sd"> <status> <basic>closed</basic> </status> <rpid:class>IM</rpid:class> <contact>im:presentity@example.com</contact> </tuple> <tuple id="thr76jk"> <status> <basic>closed</basic> </status> <rpid:class>voice</rpid:class> <contact>tel:2224055555@example.com</contact> </tuple> </presence>

<？xml version = "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：RPIDは=「URN：IETF：paramsは：XML：NS：PIDF ：RPID」エンティティ= "SIP：presentity@example.com"> <タプルIDは= "432sd"> <状態> <基本> </塩基性> </状態>閉鎖<RPID：クラス> IM </ RPID：クラス> <コンタクト> IM：presentity@example.com </接触> </タプル> <タプルID = "thr76jk"> <状態> <基本> </塩基性> </状態>閉鎖<RPID：クラス>音声</ RPID ：クラス> <接点> TEL：2224055555@example.com </接触> </タプル> </プレゼンス>

A NOTIFY is not sent to the subscriber in this case.

NOTIFYは、この場合、加入者に送信されません。

Now, a third PIDF document is created when the IM status changes to "open":

IMのステータスの変更は、「開く」する際さて、第三PIDF文書が作成されます。

<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="sip:presentity@example.com"> <tuple id="432sd"> <status> <basic>open</basic> </status> <rpid:class>IM</rpid:class> <contact>im:presentity@example.com</contact> </tuple> <tuple id="thr76jk"> <status> <basic>closed</basic> </status>

<？xml version = "1.0" エンコード= "UTF-8"？> <プレゼンスのxmlns = "URN：IETF：paramsは：XML：NS：PIDF" のxmlns：RPIDは=「URN：IETF：paramsは：XML：NS：PIDF ：RPID」実体= "一口：presentity@example.com"> <タプルID = "432sd"> <状態> <基本>開く</基本> </状態> <RPID：クラス> IM </ RPID：クラス> <コンタクト> IM：presentity@example.com </接触> </タプル> <タプルID = "thr76jk"> <状態> <基本>閉鎖</塩基性> </状態>

<rpid:class>voice</rpid:class> <contact>tel:2224055555@example.com</contact> </tuple> </presence>

<RPID：クラス>音声</ RPID：クラス> <連絡先> TEL：2224055555@example.com </連絡先> </タプル> </プレゼンス>

Notification containing both tuples is sent to the subscriber in this case:

両方のタプルを含む通知が、この場合、加入者に送られます。

7.2. Watcher Information Specific Examples

7.2. ウォッチャー情報具体的な例

The examples in this section use the winfo template-package with the presence event package [10].

このセクションの例は、プレゼンスイベントパッケージ[10]とwinfoテンプレート・パッケージを使用します。

Watcher information to a Presentity:

プレゼンに情報をウォッチャ：

<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" state="full"> <watcher-list resource="sip:presentity@example.com" package="presence"> <watcher status="active" id="sr8fdsj" duration-subscribed="509" expiration="20" event="approved">sip:watcherA@example.com"</watcher> <watcher status="pending" id="sr8fdsj" duration-subscribed="501" expiration="100" event="subscribe">sip:watcherB@example.com"</watcher> <watcher status="terminated" id="sr8fdsj" duration-subscribed="500" expiration="0" event="rejected">sip:watcherC@example.com"</watcher> <watcher status="active" id="sr8fdsj" duration-subscribed="20" expiration="30" event="approved">sip:watcherD@example.com"</watcher> </watcher-list> </watcherinfo>

<xmlのバージョン= "1.0"？> <watcherinfoのxmlns = "壷：IETF：のparams：XML：NS：watcherinfo" バージョン= "0" の状態= "フル"> <ウォッチャーリストリソース= "一口：プレゼン例@ .COM "パッケージ= "存在"> <ウォッチャーステータス= "アクティブ" ID = "sr8fdsj" 期間、加入= "509" 満了= "20" イベント= "承認"> SIP：watcherA@example.com" </ウォッチャー> <ウォッチャーステータス= "保留" ID = "sr8fdsj" 期間、加入= "501" 満了= "100" イベントは= "加入"> SIP：watcherB@example.comは "</ウォッチャー> <ウォッチャステータス="「終了しますID = "sr8fdsj" 期間、加入= "500" 満了= "0" イベント= "拒否"> SIP：watcherC@example.com "</ウォッチャー> <ウォッチャステータス=" アクティブ」ID = "sr8fdsj" 期間、加入= "20" 満了= "30" イベント= "承認"> SIP：watcherD@example.com "</ウォッチャー> </ウォッチャーリスト> </ watcherinfo>

7.2.1. Watcher Subscriber Makes Subscription to Get All the Information about Active Watchers

7.2.1. ウォッチャー加入者は、Activeウォッチャーに関するすべての情報を取得する契約を作ります

SUBSCRIBE request from the presentity including the filter:

フィルタなどのプレゼンからSUBSCRIBEリクエスト：

SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag:12341111 Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 3600 Event: Presence.winfo Contact: sip:presentity@client.example.com Content-Type: application/simple-filter+xml Content-Length: ...

：<presentity@example.com SIP：>：presentity@example.com経由：SIP / 2.0 / TCP client.example.com:5060;branch=z9hG4bKxjfdsjfkにSIPをSUBSCRIBE <一口：presentity@example.com>;タグ：12341111コールID：CSEQ 32432udfidfjmk342：1は、SUBSCRIBEの有効期限：3600イベント：Presence.winfo連絡先：SIP：presentity@client.example.comのContent-Type：アプリケーション/シンプルフィルタ+ XMLコンテンツ-長さ：...

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"> <ns-bindings> <ns-binding prefix="wi" urn="urn:ietf:params:xml:ns:watcherinfo"/> </ns-bindings> <filter id="123" uri="sip:presentity@example.com"> <what> <include> /wi:watcherinfo/wi:watcher-list[@package="presence"]/ wi:watcher[@status="active"] </include> </what> </filter> </filter-set>

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタ・セットのxmlns = "壷：IETF：のparams：XML：NS：簡単なフィルター"> <NS-バインディング> <プレフィックスをNS-結合= "のWi" URN = "URN：IETF：paramsは：XML：NS：watcherinfo" /> </ NS-バインディング> <フィルタID = "123" URI = "SIP：presentity@example.com"> <何を> <含みます> /ウィスコンシン州watcherinfo /のWi：ウォッチャーリスト[パッケージ@ = "存在"] /ウィスコンシン州ウォッチャー[@ステータス= "アクティブ" </ include>の</何> </フィルタ> </フィルタセット>

Notification to the subscriber:

加入者への通知：

NOTIFY sip:presentity@client.example.com SIP/2.0 Via: SIP/2.0/TCP presence.example.com:5060;branch=z9hG4bKxjfder To: sip:presentity@example.com;tag:12341111 From: sip:presentity@example.com;tag:232321 Call-ID: 32432udfidfjmk342 Cseq: 1 NOTIFY Contact: sip:presentity@server.example.com Event: Presence.winfo

SIP NOTIFY：presentity@client.example.comをSIP / 2.0経由：SIP / 2.0 / TCP presence.example.com:5060;branch=z9hG4bKxjfderへ：SIP：presentity@example.com;タグ：12341111から：SIP：プレゼン@ example.com;タグ：232321コールID：32432udfidfjmk342 CSEQ：1連絡先をNOTIFY：SIP：presentity@server.example.comイベント：Presence.winfo

Content-Type: application/watcherinfo+xml Content-Length: ...

コンテンツタイプ：アプリケーション/ watcherinfo + XMLコンテンツ-長さ：...

7.2.2. Watcher Subscriber Requests Information of Watchers with Specific Subscription Duration Conditions

7.2.2. ウォッチャー加入者は、特定のサブスクリプション期間の条件でウォッチャーの情報を要求します

SUBSCRIBE request from the presentity including the filter:

フィルタなどのプレゼンからSUBSCRIBEリクエスト：

SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com>;tag:12341111 From: <sip:presentity@example.com> Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 0 Event: Presence.winfo Contact: <sip:presentity@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...

一口にSUBSCRIBE：presentity@example.com経由：SIP / 2.0 / TCP client.example.com:5060;branch=z9hG4bKxjfdsjfkへ：<SIP：presentity@example.com>;タグ：12341111から：<一口例：@プレゼン。 COM>コール-IDを：32432udfidfjmk342 CSEQ：1 SUBSCRIBE有効期限：0イベント：Presence.winfo連絡先：<SIP：presentity@client.example.com>のContent-Type：アプリケーション/シンプルフィルタ+ XMLコンテンツ-長さ：...

</filter> </filter-set>

</フィルタ> </フィルタセット>

Notification to the subscriber:

加入者への通知：

Content-Type: application/watcherinfo+xml Content-Length: ...

コンテンツタイプ：アプリケーション/ watcherinfo + XMLコンテンツ-長さ：...

7.2.3. Watcher Subscriber Requests Specific Watcher Info on Specific Triggers

7.2.3. ウォッチャー加入者は、特定のトリガに特定のウォッチャー情報を要求します

This filter selects watcher information notifications [9] to be sent when the pending subscription status has changed from "pending" to "terminated". In the notification, only the watchers that have a status of "terminated" and an event of "rejected" are included.

このフィルタは、保留中のサブスクリプション・ステータスが「終了」に「保留」から変更されたときに[9]ウォッチャ情報通知を送信することを選択します。通知では、「終了」の状態と「拒否」のイベントを持っているだけウォッチャーが含まれています。

SUBSCRIBE request from the Watcher Subscriber including the filter:

フィルタを含むウォッチャー加入者からの要求をSUBSCRIBE：

SUBSCRIBE sip:presentity@example.com Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKxjfdsjfk To: <sip:presentity@example.com>;tag:12341111

一口にSUBSCRIBE：presentity@example.com経由：SIP / 2.0 / TCP client.example.com:5060;branch=z9hG4bKxjfdsjfkへ：<SIP：presentity@example.com>;タグ：12341111

From: <sip:presentity@example.com> Call-ID: 32432udfidfjmk342 Cseq: 1 SUBSCRIBE Expires: 0 Event: Presence.winfo Contact: <sip:presentity@client.example.com> Content-Type: application/simple-filter+xml Content-Length: ...

From：<SIP：presentity@example.com>コールID：32432udfidfjmk342 CSEQ：1 SUBSCRIBE有効期限：0イベント：Presence.winfo連絡先：<SIP：presentity@client.example.com>のContent-Type：アプリケーション/シンプルフィルタ+ XMLコンテンツ-長さ：...

<?xml version="1.0" encoding="UTF-8"?> <filter-set xmlns="urn:ietf:params:xml:ns:simple-winfo-filter"> <ns-bindings> <ns-binding prefix="wi" urn="urn:ietf:params:xml:ns:watcherinfo"/> </ns-bindings> <filter id="123" uri="sip:presentity@example.com"> <what> <include> /wi:watcherinfo/wi:watcher-list[@package="presence"]/ wi:watcher[@status="terminated" and @event="rejected"] </include> </what> <trigger> <changed from="pending" to="terminated"> //@status </changed> </trigger> </filter> </filter-set>

<？xml version = "1.0" エンコード= "UTF-8"？> <フィルタセットのxmlns = "URN：IETF：paramsは：XML：NS：単純winfoフィルタ"> <NS-バインディング> <NS-結合接頭辞= "のwi" 壷= "壷：IETF：のparams：XML：NS：watcherinfo" /> </ NS-バインディング> <フィルタID = "123" のuri = "一口：presentity@example.com"> <何を> </ include>の</何> <トリガーウォッチャー[ステータス@ = "終了" と@イベント= "拒否"]：[パッケージ@ = "存在"] /のWiウォッチャーリスト：watcherinfo /ウィスコンシン州/のWi <include>のを> <</フィルタリング設定</フィルタ> </変更> </トリガー> = "終了"> // @状態に= "保留" から変更>

At some point during the subscription, a second Winfo document is created due to some change:

購読中のある時点で、第二Winfo文書が何らかの変化に作成されます。

<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" state="full"> <watcher-list resource="sip:presentity@example.com" package="presence"> <watcher status="active" id="sr8fdsj" duration-subscribed="509" expiration="20" event="approved">sip:watcherA@example.com"</watcher> <watcher status="terminated" id="sr8fdsj" duration-subscribed="501" expiration="100" event="rejected">sip:watcherB@example.com"</watcher> <watcher status="terminated" id="sr8fdsj" duration-subscribed="500" expiration="0" event="rejected">sip:watcherC@example.com"</watcher> <watcher status="active" id="sr8fdsj" duration-subscribed="20" expiration="30" event="approved">sip:watcherD@example.com"</watcher> </watcher-list> </watcherinfo>

<xmlのバージョン= "1.0"？> <watcherinfoのxmlns = "壷：IETF：のparams：XML：NS：watcherinfo" バージョン= "0" の状態= "フル"> <ウォッチャーリストリソース= "一口：プレゼン例@ .COM "パッケージ= "存在"> <ウォッチャーステータス= "アクティブ" ID = "sr8fdsj" 期間、加入= "509" 満了= "20" イベント= "承認"> SIP：watcherA@example.com" </ウォッチャー> <ウォッチャーステータス= "終了" ID = "sr8fdsj" 期間、加入= "501" 満了= "100" イベント=> SIPを "拒否"：watcherB@example.com "</ウォッチャー> <ウォッチャのステータス="「終了ID = "sr8fdsj" 期間、加入= "500" 満了= "0" イベント= "拒否"> SIP：watcherC@example.com "</ウォッチャー> <ウォッチャステータス=" アクティブ」ID = "sr8fdsj" 期間、加入= "20" 満了= "30" イベント= "承認"> SIP：watcherD@example.com "</ウォッチャー> </ウォッチャーリスト> </ watcherinfo>

Notification to the subscriber is created, taking into account the <trigger> and <what> elements:

加入者への通知は、アカウントに、<トリガー>と<何>要素を取って、作成されます。

Content-Type: application/watcherinfo+xml Content-Length: ...

コンテンツタイプ：アプリケーション/ watcherinfo + XMLコンテンツ-長さ：...

<xmlのバージョン= "1.0"？> <watcherinfoのxmlns = "壷：IETF：のparams：XML：NS：watcherinfo" バージョン= "0" の状態= "フル"> <ウォッチャーリストリソース= "一口：プレゼン例@ .COM "パッケージ= "存在"> <ウォッチャーステータス= "終了" idは= "sr8fdsj" 期間、加入= "501" 満了= "100" イベント= ""> SIP：watcherB@example.com" 拒否</ウォッチャー> <ウォッチャーステータス= "終了" ID = "sr8fdsj" 期間、加入= "500" 満了= "0" イベント= "拒否"> SIP：watcherC@example.com "</ウォッチャー> </ウォッチャーリスト> < / watcherinfo>

8. Security Considerations

8.セキュリティの考慮事項

The presence of filters in the body of a SIP message has 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. Authentication can be achieved using the Digest Authentication mechanism described in [2]. The authorisation decision is based on the permissions that the resource (notifier) has given to the watcher. An example of such auhorisation policy can be found in [11].

SIPメッセージの本体内のフィルタの存在は、要求がサーバで処理される方法に大きな影響を与えます。その結果、この拡張機能を含むメッセージを認証および承認することが特に重要です。認証は、[2]に記載のダイジェスト認証機構を使用して達成することができます。認可判断は、リソース（通知）をウォッチャに与えられたことを権限に基づいています。そのようなauhorisationポリシーの例は、[11]に見出すことができます。

Processing of requests and looking up filters requires set operations and searches, which can require some amount of computation. This enables a DoS attack whereby a user can send requests with substantial numbers of messages with large contents, in the hopes of overloading the server. To counter this, the server can establish a limit on the number of occurrences of the <what>, <changed>, <added>, and <removed> elements that are allowed in the filters. A default limit of 40 is RECOMMENDED; however, servers may raise or lower the limit depending upon their specific engineered capacity.

リクエストの処理やフィルタを調べるには、計算のいくつかの量を必要とすることができ、設定された操作と検索を必要とします。これは、ユーザーがサーバーに過負荷をかけることを期待して、大規模な内容のメッセージがかなりの数にリクエストを送信することができるDoS攻撃を可能にします。これに対抗するために、サーバはフィルタで許可されている<何か>、、<追加> <変更>、および<削除>要素の出現回数に制限を設定することができます。 40のデフォルトの制限値が推奨されます。ただし、サーバーは、その具体的な設計能力に応じて、上限を引き上げるか、低下させることができます。

Requests can reveal sensitive information about a User Agent's (UA's) capabilities. If this information is sensitive, it SHOULD be encrypted using SIP S/MIME capabilities [6]. All package-specific security measures MUST be followed.

要求は、ユーザエージェントの（UAの）機能に関する機密情報を明らかにすることができます。この情報に敏感である場合、それはSIPのS / MIME機能を使用して暗号化されるべきである[6]。すべてのパッケージ固有のセキュリティ対策に従わなければなりません。

Propagating filters in SUBSCRIBE requests to foreign domains reveals sensitive information about a user's resource lists. It is therefore required that an RLS does not forward a filter if that filter is addressed to a resource that is under the administrative domain of the RLS, but that is not on the resource list. Section 4.1 shows an example where such a scenario can occur.

外部ドメインへのSUBSCRIBEリクエストでフィルタを伝播することは、ユーザーのリソースリストに関する機密情報を明らかにします。したがって、そのフィルタがRLSの管理ドメインの下にあるリソースにアドレス指定されている場合は、RLSフィルタを転送しないことを要求され、それは、リソースのリストに含まれていません。セクション4.1は、このようなシナリオが発生する可能性の例を示しています。

Note that a filtered document located at a subscriber may project false reality. For example, if a subscriber asked to be notified when a resource has changed his presence state from "closed" to "open" but not from "open" to "closed", then the subscriber may afterwards be under the false impression that the resource's presence state is "open", even long after the resource has changed it to "closed". Therefore, subscribers need to be sure what they put in a filter, understand what they asked for, and be prepared to be out of sync with the real state of a resource.

加入者に位置フィルタリング文書が偽の現実を投影してもよいことに注意してください。加入者が通知されるように要求された場合たとえば、リソースが「開く」を「閉」ではなく「開く」から「閉」から彼の存在の状態が変更されたときに、その後、加入者は、後で間違った印象の下にあってもよいこと、リソースのプレゼンス状態は、長くてもリソースがそれを変更した後に「閉」するために「オープン」です。したがって、加入者は、彼らがフィルターに入れたものを確認する必要があり、彼らが求めたものを理解し、リソースの実際の状態と同期しなくするために準備すること。

9. IANA Considerations

9. IANAの考慮事項

A new event-reason-value "badfilter" is defined to represent the event where the filter is not well formed and/or not accepted. No IANA registration is required for this value.

新しいイベント理由値「badfilter」はフィルタがよく受け入れ形成及び/又はないれていないイベントを表すように定義されています。いいえIANA登録は、この値は必要ありません。

10. Acknowledgements

10.謝辞

The authors would like to thank George Foti, Tim Moran, Sreenivas Addagatla, Juha Kalliokulju, Jari Urpalainen, and Mary Barnes for their valuable input.

著者は、彼らの貴重な入力のためのジョージFOTI、ティム・モラン、Sreenivas Addagatla、ユハKalliokulju、ヤリUrpalainen、とメアリー・バーンズに感謝したいと思います。

11. References

11.参考文献

11.1. Normative References

11.1. 引用規格

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

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

[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。

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

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

[4] Roach, A.B., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4663, September 2006.

[4]ローチ、A.B.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのAのセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4663、2006年9月。

[5] 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.

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

[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[6] Ramsdell、B.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。

11.2. Informative References

11.2. 参考文献

[7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.

[7]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。

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

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

[9] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.

[9]ローゼンバーグ、J.、 "ウォッチャー情報のための拡張マークアップ言語（XML）ベースのフォーマット"、RFC 3858、2004年8月を。

[10] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.

[10]ローゼンバーグ、J.、RFC 3857、2004年8月 "セッション開始プロトコル（SIP）のためのウォッチャー情報イベントテンプレート・パッケージ"。

[11] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.

[11]ローゼンバーグ、J.、 "プレゼンス認証ルール"、進歩、2006年6月での作業。

Authors' Addresses

著者のアドレス

Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway

ヒシャムkahartabila telio私書箱ボックスウィーク1203オスロ、ノルウェー

Phone: +47 2167 3544 EMail: hisham.khartabil@telio.no

電話：+47 2167 3544 Eメール：hisham.khartabil@telio.no

Eva Leppanen Nokia P.O BOX 785 Tampere Finland

エヴァLeppanen Nokiaの私書箱785タンペレ、フィンランド

Phone: +358 7180 77066 EMail: eva-maria.leppanen@nokia.com

電話：+358 7180 77066電子メール：eva-maria.leppanen@nokia.com

Mikko Lonnfors Nokia P.O BOX 321 Helsinki Finland

ミッコLönnforsノキアP.OのBOX 321ヘルシンキフィンランド

Phone: + 358 71800 8000 EMail: mikko.lonnfors@nokia.com

電話：+ 358 71800 8000 Eメール：mikko.lonnfors@nokia.com

Jose Costa-Requena Nokia P.O. Box 321 FIN-00045 NOKIA GROUP FINLAND

ホセコスタ・レケーナNokiaの私書箱ボックス321 FIN-00045 NOKIA GROUP FINLAND

Phone: +358 71800 8000 EMail: jose.costa-requena@nokia.com

電話番号：+358 71800 8000 Eメール：jose.costa-requena@nokia.com

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2006）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。