[要約] RFC 4660は、イベント通知フィルタリングの機能的な説明を提供するものであり、イベント通知のフィルタリングに関する要点をまとめています。このRFCの目的は、ネットワークデバイスやアプリケーションにおけるイベント通知の効率的な管理と制御を可能にすることです。
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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
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.
[3]では、通知者はいつでも通知を送信できると述べられていますが、通常、リソースの状態が変更されたときに送信されます。また、通知には、特定のサブスクライバーが確認できるように許可されたリソースの完全かつ現在の状態が含まれると述べています。このようなリソース状態情報の形式は、パッケージ固有です。このメモでは、パッケージの通知に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]で説明されています。
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.
このドキュメントでは、キーワード「必須」、「必須」、「必須」、「必要」、「しない」、「そうではない」、「必要」、「推奨」、「5月」、および「オプション」RFC 2119 [1]に記載されているように解釈され、準拠した実装の要件レベルを示します。
"Content" refers to the XML document that appears in a notification reflecting the state of a resource.
「コンテンツ」とは、リソースの状態を反映した通知に表示されるXMLドキュメントを指します。
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.
サーバーへのフィルターの輸送は、[5]で定義されているXMLドキュメントを購読要求の本文に挿入することによって達成されます。または、XMLドキュメントは、このドキュメントの範囲外の平均を使用してサーバーにアップロードできます。
SIP entities compliant with this specification MUST support the content type 'application/simple-filter+xml'.
この仕様に準拠したSIPエンティティは、コンテンツタイプの「アプリケーション/シンプルフィルターXML」をサポートする必要があります。
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.
このセクションでは、サブスクライブリクエストのボディでフィルターが使用される場合、サブスクライバーから必要な追加の機能を示します。それ以外の場合は、サービスの通常の操作（例：[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]で定義されているように、購読メッセージには本体が含まれている場合があります。このボディはフィルタリング情報を運びます。これらのフィルターを尊重することは、通知者の裁量であり、ローカルポリシーに依存する可能性があります。
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).
サブスクライブの本文のコンテンツは、notifierにフィルターが要求されていないことを示しているため、通知者は、通知者自身またはサービス固有のポリシーを使用してすべての通知要求を送信するように指示されます。たとえば、リストケース[4]では、フィルターが事前にサーバーにアップロードされた可能性があることに注意してください（このドキュメントの範囲外）。
If the body of the SUBSCRIBE includes the filter, the body MUST be of the MIME-Type 'application/simple-filter+xml'.
サブスクライブの本体にフィルターが含まれている場合、ボディはmimeタイプの「アプリケーション/シンプルフィルターXML」でなければなりません。
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つの購読に含めることができます。これは、フィルターに複数の<フィルター>要素を含めることによって達成されます[5]。各<フィルター>要素には、「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 [4]に任命された購読要求には、個々のリソースに固有の複数のフィルターが含まれる場合があります。これは、それらのそれぞれの要素に異なるリソースを持つ複数の<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.
さらに、サブスクライブがリストURIに運命づけられているかどうかに関係なく、単一のサブスクライブ内の単一のリソースまたはドメインに適用できるフィルターは1つだけです。つまり、サブスクリプション内の各フィルターは、1つのリソースまたは1つのドメインを一意に識別する必要があります。
A filter can be enabled and disabled using the 'enabled' attribute in the <filter> element, as described in [5].
[5]で説明されているように、<filter>要素の「有効」属性を使用して、フィルターを有効にして無効にできます。
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がフィルター内で定義されていない場合、フィルターはリクエスト-URIで識別されたリソースに適用されます。同様に、サブスクライバーはフィルターURIを定義する場合があります。リクエスト-URIがリストURI [4]の場合、フィルターURIはリストURI、サブリストのURI、またはURIがルックアップの結果であるURIの1つであるリソースリストサーバー（RLSの1つである必要があります。）、リクエスト - 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」属性の代わりに「ドメイン」属性を使用してドメインにアドレス指定することもできます。この場合、フィルターはそのドメインのリソースに適用されます。これは、サブスクリプションが異なるドメインから多くのリソースを備えたイベントリストであるリソース用である場合に使用できます。個々のリソース固有のフィルターがドメインフィルターとともに存在する場合、このリソース固有のフィルターは、任意のドメイン固有のフィルターをオーバーライドします。
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.
サブスクライバーは、既存のダイアログ内で新しいサブスクライブリクエストを再発行することにより、フィルターをリセットまたは変更できます。フィルターを含まない[終了]ダイアログ内の購読は、既存のフィルターを維持するために想定されます。これは、フィルターがダイアログ内で永続的であり、明示的に削除されることを意味します。
A subscriber requiring removal of a filter may do so by using the 'remove="true"' attribute, as defined in [5].
[5]で定義されているように、フィルターの削除を必要とするサブスクライバーは、[5]で定義されているように、「remove = "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がリストの場合、サブスクライバーは、既存のダイアログ内で新しいサブスクライブを発行し、以前にサブスクライブしたリストの一部である個々のリソースのフィルターを既存のフィルターにオーバーライドする場合があります。新しいフィルター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を変更してリソースURIを維持することでフィルターを置き換えるとエラーと見なされます。これにより、サーバーは2つのフィルターが同じリソースに配置されていると仮定します。
Again, a filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].
繰り返しますが、[5]に記載されているように、<filter>要素の「有効」属性を使用して、フィルターを無効にし、再度有効にすることができます。
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.
購読要求は、最終的な応答で確認されます。200クラスの応答は、サブスクリプションが受け入れられ、通知がすぐに送信されることを示しています。「200」の応答は、サブスクリプションが受け入れられ、フィルターが受け入れられていることを示しています。「202」の応答は、サブスクリプションが理解されていること、コンテンツタイプが受け入れられていること、および許可が認められた場合と認められていないことを示すだけです。「202」応答は、フィルターがまだ受け入れられていないことも示しています。フィルターの受け入れは、その後の通知に到着する場合があります。
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クラスの最終応答は、サブスクリプションまたはダイアログが作成されておらず、その後の通知メッセージが送信されないことを示しています。[2]および[3]に記載されているように、すべての非200クラスの最終応答には同じ意味と取り扱いがあります。
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」の応答は、コンテンツタイプ（フィルター）が理解されていることを示していますが、その側面は理解されていないか、受け入れられなかったことを示しています。
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応答が返された場合、フォローする通知には、フィルターが適用された後にリソースの現在の状態を説明する本体が含まれている場合があります。
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].
通知がサブスクリプションが終了したことを示している場合[3]、サブスクリプションは終了すると想定されます。このようなイベントでの行動は[3]でも説明されています。
If the subscription is indicated as active, NOTIFY requests are handled as described in package-specific documents and in [3].
サブスクリプションがアクティブとして示されている場合、通知リクエストは、パッケージ固有のドキュメントおよび[3]で説明されているように処理されます。
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]で定義されています。このセクションでは、リストのサブスクリプションでフィルターが存在する場合にそのようなエンティティがどのように動作するかについて説明します。
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がフィルター内で定義されていない場合、フィルターは、サブスクライブリクエストのリクエスト-URIで識別されたリソースリストに適用されます。これにより、RLSがこのサブスクリプションに発行するすべての通知にフィルターが適用されます。同じ処理は、サブスクライブリクエストのリクエスト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のRLSによるルックアップから生じるURIがURIの1つである1つのリソース用である場合、その特定のリソースのフィルターが抽出され、そのリソースに送信されたサブスクライブリクエストで伝播されます。サブスクライブリクエスト本体に複数のフィルターを使用することが可能であるため、リソースに固有のフィルターを抽出する必要があり、それのみが伝播されます。たとえば、subscribeのリクエスト-uriに値「sip：mybuddies@example.com」がある場合、「bob@example.com」はそのリストに属するリソースであり、フィルター内のURIは「SIP：bob@example.com "、ボブに固有のフィルターが抽出され、「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管理制御下にない1つのリソース用である場合、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管理制御下にあるが、サブスクリプションに対処されたリソースリストの一部ではない1つのリソース用である場合、フィルターは伝播されません。この場合、そのリソースに関する情報が存在する場合、このフィルターが発行された通知に適用されることを確認することは、RLSの責任です。
For example: If we have 2 lists, each located on its own RLS:
たとえば、2つのリストがある場合、それぞれが独自のRLにあります。
List1 (list1@example.com) on RLS1 has: bob@example.com
list2@biloxi.com
list2@biloxi.com
List2 on RLS2 has: alice@biloxi.com sarah@example.com
(Note: list2 is a resource in list1)
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は次のサブスクライブリクエストを受信します（サブスクライブはlist1に宛てられ、2つのフィルターが含まれています。1つはsarah@example.com用、もう1つはalice@biloxi.com用です）：
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>
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に示されているように、複数のフィルターを購読要求に存在することができます。セクション3.3.3に示すように、フィルターは追加または変更することもできます。このような状況では、RLSは同じリソースまたはドメインにアドレス指定されたフィルターがないことを確認する必要があります。また、「488」エラー応答でサブスクライブリクエストを拒否する必要があります。
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はクライアントがフィルターの更新を希望しないことを前提としています。[5]で定義されているように、RLSが「remove = "true" '属性を含むフィルターでサブスクリプション更新を受信した場合、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は既存のフィルターの置換として解釈されます。フィルターIDを変更してリソースURIを維持することでフィルターを置き換えると、これによりRLSが同じリソースに対して2つのフィルターが配置されていると仮定するため、エラーと見なされます。
A filter can be disabled and re-enabled using the 'enabled' attribute in the <filter> element, as described in [5].
[5]に記載されているように、<filter>要素の「有効」属性を使用して、フィルターを無効にし、再度有効にすることができます。
SIP entities compliant with this specification MUST support content-type 'application/simple-filter+xml'.
この仕様に準拠したSIPエンティティは、コンテンツタイプの「アプリケーション/シンプルフィルターXML」をサポートする必要があります。
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.
このセクションでは、サブスクライブリクエストのボディでフィルターが使用されている場合、通信器から必要な追加の機能を示します。それ以外の場合は、通常のパッケージ固有の機能に従います。
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'.
Notifierは、コンテンツタイプのヘッダーフィールドを調べ、コンテンツタイプ 'アプリケーション/シンプルフィルター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クラスの応答は、サブスクリプションが受け入れられ、通知がすぐに送信されることを示しています。「200」の応答は、サブスクリプションが受け入れられ、ユーザーが承認され、フィルターが受け入れられることを示しています。「202」の応答は、サブスクリプションが理解されていることを示しているだけでなく、許可が認められた場合と認められていない場合があることを示しています。「202」の応答は、フィルターがまだ受け入れられていないことも示しています。フィルターの受け入れは、その後の通知に到着する場合があります。
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に示されているように、複数のフィルターを購読要求に存在することができます。セクション3.3.3に示すように、フィルターは追加または変更することもできます。このような状況では、サーバーは同じリソースまたはドメインにアドレス指定されたフィルターがないことを確認する必要があります。その場合、「488」エラー応答でサブスクライブリクエストを拒否する必要があります。
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がフィルター内で定義されていない場合、フィルターはリクエスト-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に関連付けられたコンテンツで送信されたすべての通知に適用されます。フィルター内のリクエスト-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は、この通知者が責任を負わないドメインを含む「ドメイン」属性を使用してフィルターを無視する必要があります。通知者は、そのようなフィルターを送信する通知に適用してはなりません。ドメインに属する通知者は、ポリシーが特に指示しない限り、そのサブスクリプションに送信するすべての通知にフィルターを適用する必要があります。
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.
サーバーがフィルターが指定されていない（空のペイロード）がないサブスクリプション更新要求を受信した場合、クライアントがフィルターの更新を希望しないことを前提としています。[5]で定義されているように、「remove = "true" '属性を含むフィルターでサブスクリプション更新が受信された場合、サーバーは、クライアントがフィルター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を変更してリソースURIを維持することでフィルターを置き換えるとエラーと見なされます。これにより、サーバーは2つのフィルターが同じリソースに配置されていると仮定します。
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.
フィルターでサブスクライブを受信すると、サブスクリプションが持続している限り、紹介者はフィルターを保持する必要があります。フィルターは、ボディのフィルターを含む再サブスクライブを送信することにより、既存のサブスクリプション（アクティブなダイアログ内）に組み込むことができます。
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.
サブスクライブに送信された応答が「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ヘッダーフィールドにリストされている形式の1つ、または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 <what>要素のみを備えたフィルターは、リソース状態に変更があるときはいつでも、要求されたリソース状態情報をその<what>要素に送信します。
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 <trigger>要素のみを備えたフィルターは、トリガーと一致するリソース状態に変更がある場合はいつでも、すべてのリソース状態情報を送信します。
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 <what>および<trigger>要素を備えたフィルターは、トリガーに一致するリソース状態に変更がある場合はいつでも、要求されたリソース状態情報をその<what>要素に送信します。
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.
フィルターが再度有効になっている場合（「有効」属性を「true」に設定するか、「有効」属性を省略することにより）、notifierは、それを有効にするサブスクライブリクエストによってフィルターが配置されたように動作します。セクション5.3.1に記載されているように、即時の通知ルールが適用されます。
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.
送信される通知が元のサブスクライブへの2xx応答の直後に送信されたものである場合、フィルターの処理が時間がかかりすぎない場合を除き、その内容はフィルター<what>要素に従って入力する必要があります。「202」サブスクライブリクエストへの応答とサブスクリプションを終了しています。フィルターの処理に時間がかかりすぎている場合、送信される通知要求が空になるか、そのサブスクライバーに承認された事前に構成された値を入力する場合があります。フィルターを適用すると、コンテンツが配信されない場合、通知は空のコンテンツで送信する必要があります。フィルターに<trigger>要素が含まれている場合、notifierは最初の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]).
コンテンツフィルターへの入力は、パッケージ固有の仕様（例：[8]および[10]）に従って導出されたパッケージ固有のXMLドキュメント（[7]および[9]）です。
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.
コンテンツは、フィルターの<what>要素の式に従ってフィルタリングされます。式は、配信された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に含まれています。<what>要素の式によって示されるXML要素および/または属性は、サブスクライバーが確認することが許可されているアイテムでなければなりません。そうでない場合は、Notifierポリシーがnotifierの動作を決定します（フィルター、フィルターの一部を無視したり、フィルターを完全に拒否したりできます）。実装者は、このような実装決定を慎重に検討する必要があります。サブスクライバーは、許可されたコンテンツを認識していない可能性があるため、不正なコンテンツを要求するフィルターが含まれる可能性が最も高いです。したがって、通知者は、不正な情報を要求しているフィルターの部分を無視することをお勧めします（つまり、不正なコンテンツが要求される<filter>要素のフィルターは無視されます）。通知者が丁寧なブロッキングを使用している場合、通知者は、不正な要素または属性に偽の情報を含む通知を配信し、その後フィルターを適用することを選択できます。
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ドキュメントにフィルターを適用した結果が非Valid XMLドキュメントである場合、紹介者は元のXMLドキュメントから新しく策定されたドキュメントに要素と属性を追加する必要があります。有効であること。
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つの<filter>要素内にいくつかの<trigger>要素があります。<trigger>要素のいずれかの基準が満たされている場合、通知を生成する必要があります。
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).
<Changed>要素、<Added>要素、または<Removed>要素の式で示される項目（XML要素および/または属性）は、サブスクライバーがアクセスすることを許可されているアイテムでなければなりません。そうでない場合は、Notifierポリシーがnotifierの動作を決定します（フィルター、フィルターの一部を無視したり、フィルターを完全に拒否したりできます）。
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ドキュメントがフィルター形式のXMLスキーマ[5]と整合していない無効なフィルター定義の場合、通信器は「488」応答でサブスクライブリクエストを拒否します。応答の警告ヘッダーフィールドは、フィルターが受け入れられなかった理由についてより良い兆候を与える可能性があります。サブスクリプションが「202」応答で受け入れられたが、その後無効なフィルターが発見された場合、値「終了」のサブスクリプション状態の通知が送信されます。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.
<what>または<trigger>要素が空である場合、宛先は要素が存在しないかのように進みます。
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.
フィルターのサブスクライバーは、サブスクライブリクエスト本体として挿入されたXMLドキュメントが適切に形成され、有効であることを確認する必要があります。サブスクライバーは、拡張機能スキーマにアクセスし、XMLドキュメントを検証できない限り、拡張要素または属性をXMLドキュメントに挿入してはなりません。XMLドキュメントNotifierは、このXMLドキュメントに適用可能なアクセスを備えた拡張スキーマを含むスキーマに従ってXMLドキュメントを検証できます。
The following sections include filtering examples for Presence and Watcher Information. The format of filter is according to [5].
次のセクションには、存在感とウォッチャー情報のフィルタリング例が含まれています。フィルターの形式は[5]に従ってです。
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.
このセクションでは、存在情報フィルタリングソリューションが利用される3つのユースケースについて説明します[8]。最初のユースケースでは、ウォッチャーは、特定のプレゼンテーションのメッセージング固有の情報を取得することに興味があります。2番目のユースケースでは、ウォッチャーは、現在のコミュニケーションに利用可能なコミュニケーション手段と連絡先住所に関する情報を取得することに関心があります。3番目のケースは、プレゼンテーションがトリガーを要求して通知を受信する方法を示しています。
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つのタプルが含まれています。1つはインスタントメッセージング用、もう1つは音声関連情報用です。
<?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>
</tuple>
</presence>
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".
フィルタリングされたコンテンツは、式で示されています。この式は、<basic>要素とすべての親要素（つまり、<status>、<tuple>、およびそのルート要素）、<class>要素、および<contact>要素を選択します。<class>要素に「mms」、「sms」、または「im」が含まれている場合、フィルターは一致します。
In this case, the notification includes the contents of the tuple that has the value "IM" in its <class> element.
この場合、通知には、<クラス>要素に値「IM」を持つタプルの内容が含まれます。
SUBSCRIBE request from the subscriber including filter:
フィルターを含むサブスクライバーからのサブスクライブリクエスト：
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: ...
<?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
</include>
<include type="xpath">
//pidf:tuple[rpid:class="IM" or rpid:class="SMS"
or rpid:class="MMS"]/pidf:contact
</include>
</what>
</filter>
</filter-set>
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: ...
<?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>
</presence>
The subscriber makes a subscription to the presentity's available communication means. The subscription includes the content-limiting filter.
サブスクライバーは、プレゼンテーションの利用可能な通信手段のサブスクリプションを作成します。サブスクリプションには、コンテンツ制限フィルターが含まれています。
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 <basic> element's value is "open".
フィルタリングされたコンテンツは、式で示されています。この式は、<basic>要素とすべての親要素（つまり、<status>、<tuple>、およびそのルート要素）、<class>要素、および<contact>要素を選択します。<basic>要素の値が「開いている」場合、フィルターは一致します。
In this case, the notification returns the contents of the tuple that has the value "open" inside the <status> element.
この場合、通知は、<station>要素内に値「開いている」値を持つタプルの内容を返します。
SUBSCRIBE request from the subscriber including filter:
フィルターを含むサブスクライバーからのサブスクライブリクエスト：
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: ...
<?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>
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: ...
<?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="thr76jk">
<status>
<basic>open</basic>
</status>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
The subscriber subscribes to the presentity, specifying in the filter that it wants notifications only when the <basic> element has changed to value "open".
サブスクライバーは、<basic>要素が値「オープン」に変更された場合にのみ通知が必要であることをフィルターで指定するプレゼンティを購読します。
SUBSCRIBE request from the subscriber including filter:
フィルターを含むサブスクライバーからのサブスクライブリクエスト：
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: ...
<?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
</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":
サブスクリプション中のある時点で、2番目の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>
A NOTIFY is not sent to the subscriber in this case.
この場合、通知はサブスクライバーに送信されません。
Now, a third PIDF document is created when the IM status changes to "open":
現在、IMステータスが「オープン」に変更されたときに3番目の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>
<rpid:class>voice</rpid:class>
<contact>tel:2224055555@example.com</contact>
</tuple>
</presence>
Notification containing both tuples is sent to the subscriber in this case:
この場合、両方のタプルを含む通知がサブスクライバーに送信されます。
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: ...
<?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>
</tuple>
</presence>
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>
SUBSCRIBE request from the presentity including the filter:
フィルターを含むプレゼントからのリクエストをサブスクライブする：
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: ...
<?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>
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
Content-Type: application/watcherinfo+xml
Content-Length: ...
<?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="active"
id="sr8fdsj"
duration-subscribed="20"
expiration="30"
event="approved">sip:watcherD@example.com"</watcher>
</watcher-list>
</watcherinfo>
SUBSCRIBE request from the presentity including the filter:
フィルターを含むプレゼントからのリクエストをサブスクライブする：
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: ...
<?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[@duration-subscribed>500]
</include>
</what>
</filter>
</filter-set>
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
Content-Type: application/watcherinfo+xml
Content-Length: ...
<?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-list>
</watcherinfo>
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 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: ...
<?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>
At some point during the subscription, a second Winfo document is created due to some change:
サブスクリプション中のある時点で、いくつかの変更により2番目の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>
Notification to the subscriber is created, taking into account the <trigger> and <what> elements:
サブスクライバーへの通知は、<trigger>および<what>要素を考慮して作成されます。
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
Content-Type: application/watcherinfo+xml
Content-Length: ...
<?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="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-list>
</watcherinfo>
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 Policyの例は、[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.
リクエストの処理とフィルターの検索には、設定された操作と検索が必要であるため、ある程度の計算が必要です。これにより、ユーザーは、サーバーに過負荷をかけることを期待して、ユーザーが大きなコンテンツを持つかなりの数のメッセージでリクエストを送信できるようになります。これに対抗するために、サーバーは、フィルターで許可されている<what>、<dhanged>、<added>、<removed>要素の発生数の制限を確立できます。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.
外部ドメインへのサブスクライブリクエストでフィルターを伝播すると、ユーザーのリソースリストに関する機密情報が明らかになります。したがって、そのフィルターが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.
サブスクライバーにあるフィルタリングされたドキュメントは、誤った現実を投影する可能性があることに注意してください。たとえば、サブスクライバーがリソースが存在状態を「閉じて」から「オープン」から「オープン」から「閉じた」に変更したときに通知を求めた場合、その後、サブスクライバーはリソースの誤った印象を受けている可能性があります。リソースが「閉じた」に変更されてから、存在状態は「オープン」です。したがって、購読者は、フィルターに入れたものを確認し、何を求めているかを理解し、リソースの実際の状態と同期する準備をする必要があります。
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登録は必要ありません。
The authors would like to thank George Foti, Tim Moran, Sreenivas Addagatla, Juha Kalliokulju, Jari Urpalainen, and Mary Barnes for their valuable input.
著者は、ジョージ・フォティ、ティム・モラン、スリーニバス・アダガトラ、ジュハ・カリオクルジュ、ジャリ・ウルパラネン、メアリー・バーンズの貴重な意見に感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[3] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[3] Roach、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] Roach、A.B.、Campbell、B。、およびJ. Rosenberg、「リソースリストのセッション開始プロトコル（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. Costa-Requena、「イベント通知フィルタリング用の拡張可能なマークアップ言語（XML）ベースの形式」、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。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[7] Sugano、H.、Fujimoto、S.、Klyne、G.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年8月。
[8] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[9] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[9] Rosenberg、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] Rosenberg、J。、「セッション開始プロトコル（SIP）のウォッチャー情報イベントテンプレートパッケージ」、RFC 3857、2004年8月。
[11] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.
[11] Rosenberg、J。、「プレゼンス認証ルール」、2006年6月、進行中の作業。
Authors' Addresses
著者のアドレス
Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway
Hisham Khartabil Telio P.O.ボックス1203 Vika Oslo Norway
Phone: +47 2167 3544
EMail: hisham.khartabil@telio.no
Eva Leppanen Nokia P.O BOX 785 Tampere Finland
Eva Leppanen Nokia P.O Box 785 Tampere Finland
Phone: +358 7180 77066
EMail: eva-maria.leppanen@nokia.com
Mikko Lonnfors Nokia P.O BOX 321 Helsinki Finland
Mikko Lonfors Nokia P.O Box 321 Helsinki Finland
Phone: + 358 71800 8000
EMail: mikko.lonnfors@nokia.com
Jose Costa-Requena Nokia P.O. Box 321 FIN-00045 NOKIA GROUP FINLAND
Jose Costa-Requena Nokia P.O.Box 321 Fin-00045 Nokia Group Finland
Phone: +358 71800 8000
EMail: jose.costa-requena@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。